여러 trigger가 수십만 가게의 주문 유입 반경을 동시에 바꾸며 생긴 DB deadlock, 처리 순서 역전, 결과 확인 요구를 Kafka의 key 기반 순서 보장과 Request-Reply 패턴으로 해결한 사례다. 수평 확장 비동기 처리에서도 요청자에게 정확한 완료 결과를 돌려주는 구현을 설명한다.
핵심 포인트- 같은 가게를 여러 trigger가 동시에 갱신하며 MySQL deadlock·lock timeout이 나고, rider 부족 조절 뒤 장애 조절 순서가 뒤집히면 넓은 반경이 최종값으로 남아 처리 불가 주문을 받는 문제 — 동시성 제어·정확한 순서·성공 여부 반환을 함께 만족해야 했고 distributed lock은 획득 순서 보장·실패 결과 반환이 어려움
- 가게 ID를 key로 쓰면 동일 key 변경이 같은 partition에 들어가 순서대로 consume돼 동시성·ordering을 함께 풀고, 별도 reply channel로 비동기 결과를 요청자에게 반환 — thread를 block하지 않고 broker·partition·consumer 증설로 확장 가능해 Spring의 ReplyingKafkaTemplate 채택
- request interface에 식별자·partition key·처리 type을 두고 domain별 request/reply topic을 각각 하나로 운영해 topic 폭증을 피하며, 요청마다 correlation ID·future를 map에 보관하고 consumer가 응답 header에 같은 ID를 돌려주면 매칭 — 여러 instance가 한 reply topic을 공유할 땐 instance별 UUID consumer group과 `sharedReplyTopic=true`로 rebalance 중에도 안전
왜 읽나동시성·순서·결과 반환을 동시에 요구하는 대규모 처리에서 Kafka Request-Reply를 실제로 구현하려는 개발자에게 구성 요소와 함정을 짚어준다.