You're designing a system where an OrderPlaced event needs to independently trigger inventory update, email notification, and analytics logging at different paces, while a separate CapturePayment step must be processed exactly once by exactly one worker with strict, ordered handling per account. Would you use a pub-sub topic or a point-to-point queue for each, and how would you combine them?

## Where the choice stops being academic This kind of scenario is where the pub-sub-vs-queuing decision stops being academic and becomes an actual architecture decision with real consequences, because the two workflows described have genuinely different cardinality and ordering requirements, and picking the wrong messaging primitive for either one creates real production pain. ## OrderPlaced is a fan-out requirement **Analyzing OrderPlaced first:** the defining characteristic is that three independent, mutually-unaware downstream services (inventory, email, analytics) all need to react to the same fact, each at its own pace, with no coordination between them. - This is a pure **fan-out** requirement: the publisher (the order service) should not need to know or care who's listening, and a fourth interested party, say a future fraud-scoring service, should be addable later with zero changes to the order service. - This uniquely matches pub-sub: publish OrderPlaced to a topic, and let each downstream service maintain its own independent subscription. Inventory can process instantly; email can be slower and even batch; analytics can lag by hours during a backfill, and none of that affects the others. - If this were instead implemented as three separate point-to-point queues manually filled by the order service calling three different send calls, similar fan-out behavior would result, but the order service would be coupled to knowing about every downstream consumer explicitly — adding a fourth consumer means changing the order service's code, defeating the loose-coupling benefit pub-sub is meant to provide. A topic with a fanout mechanism (native Kafka topic plus consumer groups, or a fanout exchange to per-subscriber queues) gets fan-out without that coupling. ## CapturePayment is work distribution **Analyzing CapturePayment:** the defining characteristic here is the opposite — this must happen exactly once, by exactly one worker, with correctness on ordering per account so a payment capture and any related refund/adjustment for the same account are processed in the sequence they actually occurred. - This is a point-to-point **work-distribution** problem, not a fan-out problem: multiple workers should exist purely for horizontal scaling of throughput, and each capture should be picked up and completed by exactly one of them. - If ordering matters per account, avoiding the classic bug of a refund processed before its preceding charge, plain unordered competing-consumers isn't enough — per-key ordering is needed, achieved by **partitioning**: route by account ID so all of one account's payment events land on the same partition/consumer, while still parallelizing across different accounts. This is precisely what FIFO queues with a message group ID, or Kafka partitions keyed by account ID, are built for. ## Why not force one model onto both jobs Keep them as two separate patterns rather than forcing one model to do both jobs: - Forcing CapturePayment through a naive pub-sub topic with multiple subscribers would mean every subscriber processes every capture, clearly wrong, since exactly one worker per payment is wanted, not N redundant charges. - Forcing OrderPlaced through a single point-to-point queue would mean only one of inventory/email/analytics gets each event, whichever worker wins the race, silently dropping two-thirds of the fan-out actually needed, a very common and dangerous misconfiguration bug. ## Putting both on one broker How they combine architecturally: at the messaging-technology level, two different products aren't strictly required — the right pattern needs to be applied per workflow, possibly on the same broker. | | With Kafka | With a fanout-plus-queue style toolkit | |---|---|---| | **OrderPlaced** | goes to a topic consumed by three separate consumer groups (inventory-group, email-group, analytics-group) — each group gets the full stream independently (pub-sub across groups), while within each group multiple instances can still load-balance via partitions if that group's own throughput needs it | with a fanout-plus-queue style toolkit, publishes to a fanout topic feeding three separate queues, one per downstream service, each independently drained by that service's own worker pool | | **CapturePayment** | goes to a different topic partitioned by account ID, consumed by a single consumer group (payment-workers) whose instances split partitions among themselves — competing-consumers within the group, ordering preserved per account via partition-per-key | goes to a FIFO queue with account ID as the message group ID, consumed by a pool of payment workers | ## Running both side by side Trade-offs and failure modes to watch for at this scale: - **Mixing patterns adds operational surface area.** Lag/backlog per subscription now needs monitoring for the pub-sub side, and queue depth plus DLQ health for the point-to-point side, doubling the observability surface compared to a single uniform pattern. - **Under-provisioning partition count.** A frequent principal-level mistake is under-provisioning partition count for the payment topic relative to account cardinality and volume, causing hot-partition bottlenecks once a large merchant's account concentrates disproportionate traffic on one partition — this needs sizing and periodic revisiting as traffic grows, since repartitioning an existing keyed topic is disruptive.