스택큐힙리스트

왜 WebSocket + STOMP인가?채팅·알림처럼 양방향 저지연이 필수인 기능은 HTTP Polling이나 SSE만으로 한계가 있습니다. WebSocket으로 영구 연결을 열고, STOMP 프로토콜로 채널·헤더·구독 개념을 입혀주면 메시지 라우팅이 쉬워집니다. Spring Boot는 spring-websocket 모듈 하나로 이 조합을 깔끔히 지원해 왔고, 2025년 현재 Boot 3.3에서도 설정이 거의 변하지 않았습니다.1️⃣ 의존성 한 줄implementation("org.springframework.boot:spring-boot-starter-websocket")외부 브로커(RabbitMQ, Redis Streams 등)를 쓰려면 대응 스타터를 추가하세요.2️⃣ WebSocket 설정 클래스@..

1. ‘실시간’이 필요할 때 두 갈래 길알림·라이브 피드·채팅 같은 기능을 붙이다 보면 “Server-Sent Events(SSE)로 갈까, WebSocket으로 갈까” 갈등이 온다. 두 프로토콜은 모두 HTTP 위에서 동작하지만 성격이 확연히 다르다. 오늘 글에서는 “상황별 최적 선택법”을 정리한다.2. SSE — 단방향 스트리밍, 가볍고 자동 복구까지단방향: 서버→클라이언트 전용. 클라이언트가 뭘 보낼 일 없는 뉴스·주가·알림에 최적이다.HTTP 그대로: 별도 업그레이드 없이 text/event-stream으로 열려서 프록시·로드밸런서 호환성이 높다.자동 재접속 + 체크포인트: 브라우저 EventSource가 끊기면 재연결하고, Last-Event-ID로 놓친 메시지를 이어받는다.가벼운 서버 구현: ..

대규모 서비스가 두 세 대를 넘어 수십 대로 늘어나면, 알림 시스템이 가장 먼저 삐걱댑니다. 인스턴스 A에서 새 댓글이 등록됐는데 B에 붙어 있는 사용자는 아무 소식이 없거나, 같은 알림이 두 번씩 날아오곤 하죠. 분산 Observer 패턴을 Redis Pub/Sub로 풀면, 서버 수가 늘어나도 “한 번만, 정확히” 알림을 전송할 수 있습니다.1) Pub/Sub가 Observer를 분산으로 확장하는 방법Redis의 채널(topic)에 메시지를 Publish하면, 채널을 구독(Subscribe)한 모든 인스턴스가 동시에 이벤트를 받아옵니다. “발행자–구독자” 모델이니 Subject ↔ Observer 의존성이 사라져, 서버가 몇 대든 ‘알림 복제본’을 걱정할 필요가 없습니다. 2) 기본 흐름 한 줄 요약C..