[키워드 알림] 통신 방식 비교 (Polling, SSE)

전제

• 최대 1분(60초)의 처리 지연은 허용
• 최대 동시접속자수는 1천명 가정

---

선결론

• 지연 허용(≤1분) 이면 둘 다 가능.
  • 단순함 우선 → Polling.
  • RPS/헤더 오버헤드 최소화 + 즉시성(수초~수십초) → SSE가 유리.
• 관리 차원에서 부차적으로 발생하는 소스코드 처리 비용 종류
  • Polling: 주기/백오프/지터/빈(Not Modified)응답(304)/커서 관리가 주요 비용.
  • SSE: 장기연결(하트비트), 재연결/리플레이(Last-Event-ID), 백프레셔가 주요 비용.
• SSE 방식이 적절해 보임
  • Polling 방식은 Http 요청이 많이 발생한다는 점에서 서버 과부하를 야기시킬 수 있겠다 판단했기 때문

---

비교

#1 종합

항목	Polling	SSE
동작	주기적 요청(T초)	단방향 스트리밍 연결 유지
지연	평균 ≈ T/2	이벤트 발생 즉시(수 초 내)
서버 부하 단위	RPS = U × (60/T)	동시 커넥션 = U(사용자)
코드/운영	커서/limit/hasMore, 백오프/지터, 304	하트비트, 재연결+리플레이 버퍼, 느린 소비자 처리(Backpreassure)
인증 편의	헤더 자유(토큰 회전 쉬움)	EventSource는 커스텀 헤더 제한(쿠키/쿼리 또는 fetch-stream)
언제 유리?	분 단위 지연 허용, 초저빈도 업데이트, 익숙한 구조	즉시성·효율 중시, 희소 이벤트에 사용자 많을 때

• 클라이언트는 (폴링 방식이라면) 주기적으로 HTTP 요청을 보냄
• 서버는 처리 가능한 동시/초당 요청 상한을 갖고, 상한 초과 시 다음 폴링으로 이월시키는 정책이 필요
• 초과분 무시? → 불가
  • 요청을 받아놓고 응답을 안 하면 소켓/스레드/메모리 점유가 늘어 더 위험함.
  • 무조건 200 빈 응답을 보내도 클라이언트 폴링 주기가 바뀌지 않아 폭주 지속.
  • 결론: 상한 초과 시 조기 거절(HTTP 429) 과 명시적 백오프 힌트를 제공해야 함

• Polling은 오버헤드 발생 확률이 높으며, 자원 소모율이 훨씬 높다고 함

---

클라이언트 측 처리

#1 폴링 도입 시, 클라이언트에서 진행해야 하는 처리

처리	내용	참고
주기	일정 주기로 API 요청을 보냄.	-
Backoff	재요청 시간 컨트롤.지수 백오프(log2): 2 → 4 → 8 → 16 → …	네트워크 타임아웃 문제를 안전히 처리하기 위한 재시도 전략 (Backoff, Retry Storm)
Jitter	지수 백오프에 무작위 지연을 더해 동시 재시도를 분산.	네트워크 타임아웃 문제를 안전히 처리하기 위한 재시도 전략 (Backoff, Retry Storm)
수정 없음(304)	서버에 변경이 없으면 리렌더링 생략 또는 캐시 데이터 표시.	-
Cursor	커서/페이지네이션으로 이미 본 데이터 제외 → 전송량 절감.	Understanding 5 Types of Web API Pagination

 

#2 SSE 도입 시, 클라이언트에서 진행해야 하는 처리

처리	내용	참고
Heartbeat	유휴 연결이 끊기지 않도록 서버의 keep-alive 이벤트 수신/처리.	[SSA] 서버 SSE 기능 구현
재연결/리플레이 (Last-Event-ID)	끊김 시 자동 재연결하고, Last-Event-ID로 누락 이벤트 재수신(캐시 활용 가능).	-
Backpressure(느린 소비자)	소비 속도가 생산 속도를 못 따라갈 때 읽기/쓰기 속도 조절로 과부하 방지.	Don’t Let the Stream Overwhelm You: Effectively Managing Backpressure in Spring WebFlux