메시지 큐를 두면 무엇을 얻고 무엇을 잃는가?

보내는 쪽과 받는 쪽의 시간을 떼어내는 대신 완료 확인과 재처리를 따로 설계한다. 트래픽이 몰려도 받는 쪽이 자기 속도로 처리할 수 있는 것이 가장 큰 이득이다.

큐를 두면 받는 쪽의 잠깐 장애를 요청 처리와 분리할 수 있다. 하지만 큐가 있다고 유실이 자동으로 사라지지는 않는다. 어디까지 처리했는지 확인하는 프로토콜이 필요하다.

대가도 분명하다. 주문 접수와 실제 처리 사이에 틈이 생긴다. 화면은 접수를 완료로 보이지 않고 처리 중과 실패를 따로 보여줘야 한다. 적체량과 재시도도 관측해야 한다.

confirm이 유실되면 브로커가 받았는지 발행자는 알 수 없다. 안전하게 재전송하면 중복이 생길 수 있다. 그래서 전달 보장은 큐 제품의 고정 속성이 아니라 영속·복제 설정, confirm·ack, 재전송, 컨슈머 멱등성을 합친 결과다.

순서도 파티션 수와 컨슈머 병렬성에 따라 달라진다. 같은 주문의 순서가 필요하면 같은 키를 같은 파티션으로 보내고 처리 병렬성을 그 범위에서 제한한다.