Realtime Safety

WebSocket은 연결 유지보다 계약 유지가 더 어렵다

게이트웨이는 실시간 통신의 입구이므로 인증, 이벤트 이름, 룸 경계, 서버 간 전파 규칙을 먼저 고정해야 한다.

need

진짜 실시간인가

서버가 즉시 밀어줘야 하는 채팅, 협업, 알림이면 WebSocket을 쓴다. 단순 갱신은 폴링도 후보가 된다.

connect

핸드셰이크 보호

운영 환경은 WSS, 제한된 CORS, 토큰 검증을 기본으로 두고 실패 이유를 추적한다.

계약

이벤트 계약

joinRoom, chatMessage처럼 이름과 payload 모양을 문서화하고 버전 변경 기준을 둔다.

route

룸 전파 구분

전체 방송과 to(roomId) 전파를 분리한다. 파일, 채팅방, 프로젝트처럼 경계가 되는 ID를 고른다.

scale

확장 증명

여러 인스턴스에서는 sticky session, Redis Adapter, 연결 수 메트릭이 함께 있어야 메시지가 새지 않는다.