RabbitMQ 도입 배경

• 도입 배경 MOMO 플랫폼에서 결제 처리, 실시간 알림, 도메인 간 통신에서 메시지 신뢰성이 중요했습니다. 결제 완료부터 참가자 확정까지의 메시지 전달이 보장되어야 하고, 메시지 손실 시 사용자가 요금을 지불했지만 모임에 추가되지 않는 문제가 발생할 수 있었습니다.
• 선택지
  • Redis
    • 인메모리 처리로 극도로 낮은 지연시간
    • 기본 설정에서 재시작 시 메시지 손실
    • 내장된 데드 레터 큐 메커니즘 없음
  • Apache Kafka
    • 초당 수십만 메시지 처리 가능한 높은 처리량
    • Zookeeper, 브로커, 토픽 등 복잡한 개념들
    • 6주 내에 팀 전체가 숙달하기 어려운 학습 곡선
  • RabbitMQ
    • Publisher Confirm으로 브로커 도달 확인
    • Exchange와 Routing Key를 통한 정교한 메시지 라우팅
    • 강력한 데드 레터 큐 및 재시도 메커니즘
    • Spring AMQP와의 완벽한 통합
• 최종 결정 Redis는 결제 시스템에서 요구하는 메시지 신뢰성을 제공하지 못하기 때문에 제외했습니다. Kafka는 6주 프로젝트에서 6인 팀이 감당하기에는 과도한 복잡성을 가져 제외했습니다. 따라서 RabbitMQ로 결정했습니다.