[SW Eng] 동기 vs 비동기 — 메시지 큐와 이벤트 기반 구조

동기(synchronous): 응답을 기다린 뒤 다음
  주문 → [결제 대기] → [재고 대기] → [알림 대기] → [정산 대기] → 응답
  → 한 단계라도 느리면(알림 서버 지연) 전체 응답이 멈춤. 장애가 전파됨.

비동기(asynchronous): 맡기고 즉시 다음
  주문 → 결제(동기, 꼭 필요) → 응답!
            └─ 이벤트 발행: "주문생성됨" → 큐
                              ├─ 알림 소비자(자기 속도로)
                              ├─ 정산 소비자
                              └─ 재고 소비자
  → 알림이 느려도 주문 응답은 빠름. 결합이 끊김.

핵심 판단: 사용자 응답에 꼭 필요한 것(결제 성공)만 동기로, 나머지(알림·정산·집계)는 비동기로 뺍니다. 이는 [[architecture-patterns]]의 MSA에서 서비스 간 결합을 끊는 핵심 수단이며, [[twelve-factor-app]]의 무상태·확장성과도 맞물립니다.

메시지 큐(Kafka·RabbitMQ·SQS·Redis)는 생산자(이벤트 발행)와 소비자(처리) 사이에 버퍼를 둡니다.

세 가지 이점:

• 분리(decouple): 생산자는 소비자가 누군지·살았는지 몰라도 됨.
• 완충(buffer): 스파이크를 큐가 쌓아두고 소비자가 자기 속도로 처리.
• 격리(isolation): 소비자가 죽어도 메시지가 큐에 남아 유실 안 됨, 복구 후 처리.

깊은 운영(파티션·보존기간·디스크 산정)은 [[tech-stack-reading]]에서 본 것처럼 별도 인프라 투자가 필요합니다. 큐는 '또 하나의 서버'가 아니라 클러스터·디스크·모니터링이 따르는 상태 저장 시스템입니다.

비동기의 가장 흔한 함정은 중복입니다. 대부분의 큐는 전달을 이렇게 보장합니다.

at-most-once   : 최대 한 번(유실 가능, 중복 없음) — 손실 OK인 지표 등
at-least-once  : 최소 한 번(중복 가능, 유실 없음) — 가장 흔함
exactly-once   : 정확히 한 번(이상적이나 비싸고 제약 많음)

대부분 'at-least-once' → 같은 메시지가 2번 올 수 있다!
  "주문 생성" 이벤트 중복 → 멱등 처리 안 하면 결제 2번/알림 2번

대응:

• 멱등 처리(idempotent): Idempotency Key·중복 체크로 "같은 메시지 두 번 처리해도 결과 1번"([[requirements-prd]]).
• DLQ(Dead Letter Queue): N번 실패한 메시지를 격리 보관 → 정상 흐름을 안 막고 원인 분석·재처리.
• 재시도(retry) + 백오프: 일시 장애는 점점 간격을 늘려 재시도.

PM·인프라 관점: "비동기로 빼자"는 결정엔 중복·실패·순서라는 새 문제가 따라옵니다. 멱등·DLQ·재시도 설계 없이 큐만 도입하면 중복 사고가 납니다.