클라이언트가 주기적으로 서버에 “상태 바뀌었어?”라고 묻는 방식
클라이언트가 /queue/status 요청
서버는 현재 상태 응답 (WAITING / MATCHED)
1~2초 후 다시 요청
구현이 매우 단순
HTTP만 있으면 됨 (프록시/Nginx/AWS 설정 간단)
서버/클라이언트 디버깅 쉬움
장애 시 복구도 단순
불필요한 요청 많음
실시간성 비슷하게 흉내만 냄
유저 수 많아지면 서버 부하 증가
MVP / 초기 서비스
동시 사용자 수 적음
1~2초 늦어도 괜찮은 알림
클라이언트–서버가 연결을 유지하고, 서버가 이벤트를 즉시 푸시하는 방식
클라이언트가 WS 연결
서버가 연결을 유지
매칭 성사 시 → 서버가 즉시 match_found 이벤트 전송
진짜 실시간
불필요한 요청 없음
UX가 훨씬 자연스러움
채팅/실시간 대기열 표시 등에 최적
구현/운영 복잡
연결 수 관리 필요
로드밸런서/프록시 설정 신경 써야 함
서버 장애 시 연결 복구 로직 필요
언제 적합한가
유저 수 많음
실시간 UX가 서비스 핵심
채팅/파티/상태 공유 있음
