WebSocket 끊기면 메시지를 잃어버린다
Redis Pub/Sub의 Fire-and-Forget 특성으로 WebSocket 재연결 시 메시지가 유실되는 문제를 MongoDB 기반 커서 페이지네이션으로 해결한 과정을 정리한다.
채팅방 목록 조회에 1.3초가 걸렸다
N+1 Query로 1.3초 걸리던 채팅방 목록 조회를 Fetch Join + 배치 조회 + Redis 캐싱(MGET)으로 85ms까지 최적화한 과정을 정리한다.
메시지가 뒤섞이는 채팅은 채팅이 아니다
분산 환경에서 채팅 메시지 순서를 보장하기 위해 서버 타임스탬프 + 클라이언트 정렬 + MongoDB 정렬 조회 전략을 설계한 과정을 정리한다.
빌려조잉 - 삼성 우수상, 그리고 팀원 이탈 속에서 배운 것들
C2C 공유 플랫폼 빌려조잉(6주, 6인 팀, 삼성 우수상)의 백엔드 설계와 운영을 한 글에 정리합니다. 메시징은 Kafka/RabbitMQ/NATS를 제치고 트래픽 1,000배 여유를 근거로 Redis Pub/Sub + MongoDB 영속화를 선택했고, 저장소는 직접 측정(MongoDB Insert ~5ms vs MySQL ~15ms)을 근거로 MySQL+MongoDB+Redis Polyglot Persistence를 채택했습니다. 채팅방 목록 조회는 N+1(51쿼리)을 Fetch Join + Redis MGET + Coroutine 병렬 조회로 4쿼리·1,350ms→85ms (16배)까지 줄였고, 커서 페이지네이션으로 100번째 페이지 450ms→12ms, SimpleBroker 한계를 Redis 세션 관리로 풀어 멀티 인스턴스 확장을 준비했습니다. 인증은 HttpOnly Cookie + Vite 프록시, Redis는 CVE-2025-49844 'RediShell'(CVSS 9.9) 긴급 패치(7.0.15→7.2.11 + 다층 방어). Coroutine+JPA 401 디버깅, 팀원 이탈 대응(토스 에스크로 역방향 로직, 마감 1주 전 프론트 7화면 직접 연동)까지 포함합니다.
MySQL, MongoDB, Redis를 같이 쓴 이유
채팅 시스템에서 MySQL(관계 데이터), MongoDB(메시지 저장), Redis(실시간 전달+캐싱) 세 DB를 함께 사용한 Polyglot Persistence 설계를 정리한다.