백엔드 엔지니어링수정 2026-08-29
되돌아오는 질문들 — 알림센터 설계 문답
알림센터 다섯 편의 마지막이다. 앞의 네 편이 주제별로 나눠 답한 것을 질문이 실제로 오는 세 자리로 다시 세운다 — 아직 아무것도 정하지 않은 「고를 때」, 이미 돌고 있는데 증상이 나온 「터졌을 때」, 그 판단의 근거를 남에게 대야 하는 「설명해야 할 때」다.
태그
event-driven
6편
백엔드 엔지니어링수정 2026-08-18
실시간이라는 요구가 왔을 때 — 전송 방식과 WebSocket 프로토콜
「실시간으로 만들어 달라」는 요구는 기술의 이름이 아니라 증상의 이름이다. 이 글은 서버가 먼저 말을 걸어야 하는 문제를 다섯 가지 전송 방식으로 갈라 언제 무엇을 고르는지 정하고, WebSocket을 골랐을 때 실제로 무엇이 오가는지를 핸드셰이크·프레임·하트비트 세 층에서 본다.
백엔드 엔지니어링수정 2026-08-29
알림 하나가 만들어지기까지 무엇을 지나는가 — 알림센터 설계의 지형
알림센터 다섯 편의 지도다. 좋아요 한 번이 알림 한 줄이 되기까지 어떤 서버와 어떤 저장소를 지나는지, 그 경로를 왜 조회와 생성으로 쪼개고 사이에 브로커를 끼우는지, 그리고 「파티션」·「모듈」·「이벤트」처럼 편마다 다른 것을 가리키는 낱말을 이 시리즈에서 어떤 뜻으로 쓸지를 먼저 정한다.
백엔드 엔지니어링수정 2026-08-29
한 번 이상 오는 메시지를 어떻게 한 번처럼 다루는가 — Kafka 구조와 전달 보장
브로커를 끼워 넣으면 장애가 거꾸로 번지는 경로는 사라지지만 그 대가로 지연과 중복과 순서 뒤집힘이 청구된다. 토픽과 파티션이 무엇을 정하는지, 컨슈머를 늘려도 처리량이 늘지 않는 구간이 왜 생기는지, 오프셋을 언제 커밋하느냐가 전달 보장을 어떻게 바꾸는지를 차례로 본다. 이어서 순서가 지켜지는 범위와 중복을 견디는 도메인 설계, 끝내 실패하는 한 건을 줄 밖으로 빼내는 장치까지 다룬다.
백엔드 엔지니어링수정 2026-08-18
Redis에 담을 것과 담지 않을 것 — 집합 연산부터 운영 지식까지
좋아요·구독을 Set으로 푸는 근거와 멱등 API 설계, 댓글을 Redis가 아닌 저장소에 두는 판단, 단일 스레드 모델이 낳는 운영 제약, 영속화·축출 정책·고가용성 구성을 정리한다.
백엔드 엔지니어링수정 2026-08-18
STOMP와 Spring의 WebSocket 지원 — 라우팅과 인증이 걸리는 자리
생 WebSocket은 바이트를 옮길 뿐 목적지를 모른다. 이 글은 그 공백을 STOMP가 어떤 규약으로 메우는지, Spring이 그것을 세 층위로 어떻게 감싸는지, 그리고 destination 접두사를 잘못 나누면 인가 검사가 통째로 우회되는 이유를 다룬다.