Messaging

HTTP는 동기야 — 요청 보내고 응답 올 때까지 기다리잖아. 근데 서비스 간 통신이 꼭 그래야 할까? **메시징(messaging)**은 프로듀서와 컨슈머를 디커플링해서, 한쪽이 다운돼도 메시지가 큐에 쌓여서 복구 후 처리하면 되거든.

메시지 전달 보장에는 세 수준이 있어. At-most-once는 보내고 잊기(fire and forget) — 유실될 수 있지. At-least-once는 유실은 없지만 중복 전달이 가능해서 멱등한 컨슈머가 필요해. Exactly-once는? 전송 계층에서는 불가능해. 분산 시스템에서 네트워크 불확실성 때문이야. 근데 여기서 핵심적인 구분이 있거든. "Exactly-once delivery는 불가능하지만, exactly-once processing은 가능하다." **멱등성(idempotency)**과 **중복 제거(deduplication)**를 조합하면 같은 메시지를 여러 번 받아도 결과가 같게 만들 수 있지.

메시지 처리에 실패하면 어떻게 해야 할까. 처리할 수 없는 메시지를 무한 재시도하면 큐 전체가 막혀버려. 대신 **DLQ(Dead Letter Queue)**로 보내서 나중에 조사하는 게 훨씬 나아. 컨슈머의 처리량이 프로듀서의 생산량을 못 따라가면 **백로그(backlog)**가 쌓이지. 백로그 크기 모니터링은 시스템 건강의 핵심 지표야 — 성장하는 백로그는 용량 문제의 조기 경고거든. 그냥 방치하면 큐가 터져.

메시징의 큰 장점 중 하나는 자연스러운 장애 격리야. 컨슈머가 다운되면 요청이 큐에 쌓일 뿐, 프로듀서에 연쇄 장애가 전파되지 않아. 동기 HTTP 호출이랑 결정적으로 다른 점이지. 큰 페이로드를 보내야 할 땐 Queue plus blob 패턴 — blob 스토리지에 저장하고 참조만 큐로 보내면 돼.

---

정리

13장 읽고 기억할 거 세 가지:

1. Exactly-once delivery는 불가능하지만 exactly-once processing은 멱등성으로 달성 가능해 — 이 구분이 핵심이야.
2. 메시징은 지연 시간과 탄력성의 트레이드오프 — 비동기라 느리지만 서비스를 디커플링하고 자연스러운 장애 격리를 제공해.
3. 백로그 모니터링이 필수야 — 성장하는 백로그는 용량 문제의 조기 경고 신호거든.