시나리오 템플릿

AMQP work queue 패턴 — Order Service가 RabbitMQ에 publish, 4개 Worker가 **같은 queue**를 구독해 경쟁 소비자(competing consumers)로 나눠 처리한다. 1,500 msg/s · 10초 실측: Worker 1~4가 3,730 / 3,760 / 3,751 / 3,749건 = 각자 **정확히 0.25**씩 가져간다. AMQP에는 partition이 없어 브로커가 **메시지마다** 다음 여유 consumer에게 넘기기 때문이다(prefetch로 한 consumer가 쥘 수 있는 미확인 메시지 수를 제한). Kafka와 갈리는 지점이 여기다 — Kafka는 partition 단위 배정이라 partition 3에 consumer 2면 2:1로 불균등해진다(multi-broker-production에서 실측 4,394 : 2,190). lag은 peak 80에서 0으로 회복 · 성공률 100%.

같은 6,000 RPS를 셋으로 갈라 broker마다 2,000 msg/s를 보낸다. 다른 건 "소비 상한을 무엇이 정하느냐"다 — Kafka는 3 partition × 1,000 = 3,000/s(부하의 1.5배)라 10초 뒤 lag 98로 평온하고, Redis Streams는 2,000/s로 부하와 동률이라 lag 284에서 요동하고, RabbitMQ는 단일 큐 1,400/s라 초당 600건씩 밀려 lag 6,189가 된다(consumer 13,930건 = 1,393/s). 늘리는 방법도 각각이다: Kafka는 partition 추가, RabbitMQ는 consumer + prefetch, Streams는 메모리(maxlen) 한도 안에서.

Topic을 first-class 노드로 — Kafka broker 옆에 payments/notifications 박스가 명시적. 3,000 RPS · 10초 실측: 주문 29,813건이 payments에 publish되고 같은 주문이 notifications에도 **복제** 발행되어(mirror 엣지) Kafka가 총 59,632건을 처리한다. payments를 구독하는 3 group(payments/audit/reward)과 notifications의 1 group이 **각각 29,677건**씩 받는다 — pub-sub이라 부하가 나뉘는 게 아니라 복제된다. 그 대가는 MySQL이 진다: 3개 worker가 같은 DB에 쓰므로 89,031건 · CPU 64%로 이 토폴로지에서 가장 뜨겁다. lag 278 · 성공률 100% · p50 42.2ms.

실 production 시스템처럼 3 broker 동시 사용 — Kafka(영속 log) + RabbitMQ(work queue) + Redis Streams(realtime). 2,000 RPS · 10초 실측: API가 6,618 / 6,617 / 6,617로 셋에 고르게 발행하고 성공률 100%. ★ 같은 "consumer 2대"인데 분배가 다르다: Kafka는 partition 단위 sticky 배정이라 partition 3 ÷ consumer 2 = **4,394 : 2,190 (2:1)**로 기울고, RabbitMQ는 메시지 단위 경쟁 소비자라 **3,308 : 3,306 (1:1)**로 고르다. "Kafka consumer를 늘렸는데 왜 한쪽만 바쁘지?"의 답이 이 두 숫자다. Redis Streams는 단일 consumer가 6,583건. API Server는 6대 — 1대면 상한 ≈600 RPS의 3.3배라 CPU 100% + queue-full 4,008건으로 broker 비교가 아니라 API 포화가 화면을 덮었다.