WebSocket 접속 끊김
실시간 이벤트를 놓친 사용자가 메시지가 사라졌다고 느낍니다.
대응 · 재연결 뒤 after_sequence 동기화와 heartbeat timeout을 사용합니다.
채팅 시스템 설계
연결은 끊기고, 메시지는 재시도되며, 그룹은 갑자기 커집니다. 대화 ID를 순서와 샤딩의 단위로 정하고, 영속 저장·실시간 전달·오프라인 동기화를 분리해 설계합니다.
개념 이해면접 답변운영 관점진도 저장
30초 핵심 요약
채팅은 WebSocket 연결 하나로 끝나지 않습니다. 메시지는 대화별 로그에 먼저 영속화하고, 온라인 수신자에게는 이벤트를 전달하며, 오프라인 수신자는 마지막 sequence 이후를 다시 읽습니다. 전달은 at-least-once를 허용하고 message_id로 중복을 제거합니다.
동시 접속 (설계 가정)100만 연결
일 메시지 (계산 결과)약 4억 건
순서 단위대화별 sequence
01 · REQUIREMENTS
# 요구사항실시간성과 정합성을 분리한다
발송 완료, 수신 단말 전달, 읽음은 서로 다른 상태입니다. 저장 성공을 먼저 확정하고 전달은 재시도 가능한 비동기 경로로 다룹니다.
F1연결 유지
접속 게이트웨이는 장시간 WebSocket과 heartbeat를 관리합니다.
F2대화별 순서
서버가 conversation마다 증가하는 sequence를 부여합니다.
F3재시도 안전성
같은 idempotency key의 저장은 기존 message_id를 반환합니다.
F4오프라인 복구
연결 이벤트가 아닌 영속 로그로 누락을 메웁니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처저장 경로와 전달 경로
접속 상태는 짧은 TTL 힌트이고, 메시지 로그가 정본입니다. 팬아웃·푸시·읽음 표시는 저장 결과를 소비하는 별도 경로로 둡니다.
1:1 메시지 전송과 오프라인 동기화 SVG DIAGRAM · 이벤트 전달은 재시도 가능
03 · MESSAGE FLOW
# 처리 흐름전송·전달·읽음을 분리한다
1멱등 저장
같은 client-message-uuid는 기존 message_id와 sequence를 돌려줍니다.
2순서 부여
대화 ID 샤드 안에서 append-only 로그 순서로 sequence를 정합니다.
3온라인 팬아웃
presence TTL을 조회해 현재 접속 서버에 이벤트를 보냅니다.
4재접속 동기화
마지막 확인 sequence 이후를 읽어 gap을 메웁니다.
04 · TRADEOFFS
# 트레이드오프그룹 대화의 팬아웃 선택
수신자가 많을수록 하나의 선택을 모든 대화에 고정하면 비용이나 지연이 급격히 커집니다.
선택
강점
주의점
적용 예
fan-out on write
개인 inbox 읽기가 빠름
대형 그룹에서 쓰기·저장 폭증
소규모 그룹
fan-out on read
쓰기 비용이 참여자 수에 덜 민감
읽을 때 집계 지연
대형 공지 채널
at-least-once
장애 복구·재시도 단순
message_id 중복 제거 필요
일반 채팅
대화별 순서
사용자 맥락 유지
전역 메시지 순서는 제공하지 않음
대화 타임라인
05 · FAILURE MODES
# 장애 대응연결이 끊겨도 메시지는 남아야 한다
메시지 중복 전달
재시도·ACK 유실로 같은 이벤트가 여러 번 도착합니다.
대응 · 저장과 UI에서 message_id 기준 dedupe합니다.
순서 뒤바뀜
서로 다른 경로의 이벤트가 순서를 바꿔 도착할 수 있습니다.
대응 · conversation sequence로 정렬하고 gap은 로그에서 재조회합니다.
핫 채널
대형 그룹의 fan-out lag가 일반 대화까지 밀어냅니다.
대응 · 대형 그룹 전용 파티션·배치 워커·속도 제한을 둡니다.
06 · OPERATIONS
# 운영보안·관측·비용
영역
확인할 것
판단 기준
주의점
권한
대화 참여자 검증
API·구독 모두 membership 확인
presence만 믿지 않음
관측
연결 수, 재연결률, fan-out lag
대화·샤드별 p99
평균만으로 핫 채널을 숨기지 않음
비용
연결 메모리, 보관, 첨부파일
원본 약 400GB/일 (예시)
복제·보관 기간은 별도 계산
출처
RFC 6455·RFC 8030
검토일 2026-08-23
프로토콜과 제품 보장을 혼동하지 않음
면접 모드 · 추가 질문05:00
“한 대화의 메시지 순서는 지키면서, 천만 사용자의 연결과 대형 오픈 채널을 어떻게 함께 처리하시겠습니까?”
대화 단위 샤딩재접속 복구그룹 팬아웃
NEXT CASE STUDY결제 시스템 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- RFC 6455: The WebSocket Protocol — 장시간 양방향 연결의 프로토콜 경계를 검토했다.
- RFC 8030: Generic Event Delivery Using HTTP Push — 오프라인 수신자 알림이 메시지 정본 전달과 다른 경로임을 검토했다.
- 본 문서의 규모·지연·비용 수치는 `설계 가정` 또는 `계산 결과`이며 제품 사실이 아니다.
- 주제 구성 참고: liquidslr/system-design-notes (독립 재집필, 문장·이미지 미사용)
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.