If three different services (billing, shipping, and analytics) all need to react to the same 'OrderPlaced' notification, how does supporting that differ structurally between a destructive-read queue like RabbitMQ and an append-only log like Kafka?

## Broadcasting with queues In RabbitMQ, a producer publishes to an exchange, and the exchange's type (fanout, topic, etc.) determines which bound queues receive a copy of the message; in AWS, the equivalent is SNS fan-out, where one SNS topic publishes to N subscribed SQS queues. Either way, broadcasting to three services means provisioning three physical queues, each with its own retry settings, visibility timeouts, and dead-letter queue, and the message is physically duplicated once per queue until each is acked. ## Broadcasting with a log In Kafka, a topic's partitions are read non-destructively, so the broker only needs to track per-consumer-group offsets on top of the single stored copy of each message. Adding a fourth consumer group costs zero additional storage beyond the topic's retention and requires no broker reconfiguration or producer awareness - it's a purely client-side action of creating a new group and starting to poll. ## What each was built around This difference traces back to what each technology was built around. - **Queues** were designed for the 'competing consumers' pattern: many workers pulling from ONE queue to share load, where adding a worker to the SAME queue splits the work rather than duplicating it - broadcasting to independent services is a bolt-on pattern requiring extra plumbing. - **Logs** were designed around 'publish once, many independent subscribers': broadcast-to-N is the default behavior, and load-sharing within a single logical consumer is instead achieved by splitting a topic into partitions and running multiple instances inside one consumer group. ## The trade-offs The trade-offs run in opposite directions. - **Queue-based fan-out** gives strong isolation: a spike or outage in the analytics queue can't affect billing's queue depth, each consumer can tune its own retry/backoff independently, and per-consumer dead-lettering is trivial - but it costs more upfront design, since adding a new consumer means someone has to provision a new queue and binding, and it costs more storage since the message is physically duplicated N times. - **Log-based fan-out** gives effortless extensibility - spin up a new consumer group anytime, even against history - and stores the message once, but the broker provides no automatic backpressure isolation between consumer groups: a paused or slow group just accumulates lag rather than being isolated the way a separate queue would be, and all groups share the same retention clock on the underlying data. ## Failure modes Failure modes differ correspondingly. - **On the queue side**, forgetting to bind a new queue to the exchange means that service silently receives nothing - a routing configuration bug rather than a data bug, since the exchange has no concept of an unknown subscriber. - **On the log side**, the risk is a consumer group being paused (e.g., for a deploy or incident) longer than the topic's retention window: unlike a queue where unacked messages sit indefinitely, a stalled Kafka consumer group can silently lose access to the oldest events once they age out of retention, with no alert unless someone monitors lag against the retention window specifically. ## The same latecomer, both ways A concrete scenario: - **With RabbitMQ**, engineering sets up a topic exchange named `orders` with bindings to `billing.orders` and `shipping.orders`; when analytics later needs the data, a new `analytics.orders` queue and binding must be created, and analytics only sees orders placed after that binding exists - nothing historical is recoverable from the exchange. - **With Kafka**, an `orders` topic retains 30 days of data; when the analytics team joins six months later, they create a new consumer group and can choose to start from the earliest offset still within that 30-day window or from 'now,' with no coordination needed with the producer or any other consumer group.