메시징 시스템 면접 퀴즈

메시지 큐 기초

왜 메시지 큐가 필요한가?

• 비동기 처리: 이메일 발송, 알림 등 즉시 응답 불필요한 작업
• 디커플링: 서비스 간 직접 의존 제거
• 버퍼링: 트래픽 급증 시 요청을 큐에 저장 후 처리

주요 메시지 브로커

실무 포인트

• At-least-once vs Exactly-once: 대부분 At-least-once → 멱등성 보장 필요
• 메시지 순서 보장이 필요한가? → Kafka 파티션 키 활용
• DLQ(Dead Letter Queue)로 실패 메시지 관리

이벤트 기반 아키텍처

핵심 개념

• 이벤트 발행(Publish): 서비스가 상태 변경 시 이벤트 발행
• 이벤트 구독(Subscribe): 관심 있는 서비스가 이벤트 수신
• 서비스 간 직접 호출 없이 느슨한 결합 유지

패턴

실무 포인트

• 주문 → 결제 → 배송: 각 단계를 이벤트로 연결
• 이벤트 유실 방지: Outbox 패턴 (DB+이벤트 원자적 저장)
• 디버깅 어려움 → 이벤트 추적(Tracing) 도구 필수

메시지 전달 보장

세 가지 수준

• at-most-once: 보내고 잊는다. ack가 없어도 재전송하지 않음 → 유실 가능, 중복 없음
• at-least-once: ack를 못 받으면 재전송 → 유실 없음, 중복 가능. 실무 기본값
• exactly-once: 정확히 한 번. 조건이 붙는 제한적 보장이다

커밋 순서가 등급을 결정한다

exactly-once의 흔한 오해

• Kafka의 exactly-once는 트랜잭션으로 읽기-처리-쓰기가 Kafka 안에서 끝날 때 성립한다
• 컨슈머가 외부 DB나 결제 API를 호출하는 순간 브로커의 보장은 거기서 끊긴다
• 종단간 한 번은 결국 소비자 멱등성으로 만든다

실무 포인트

• 기본 선택은 at-least-once + 멱등 소비자. exactly-once를 옵션으로 켜는 문제가 아니다
• 유실이 허용되는 지표와 클릭 로그 수집은 at-most-once로 비용을 줄인다
• ack 타임아웃이 실제 처리 시간보다 짧으면 정상 처리 중에도 중복이 폭증한다