In a message broker, what's the practical difference between publishing to a queue versus publishing to a topic, in terms of how many consumers receive each message?

## The two shapes A **queue** is a single ordered buffer of messages with one logical set of consumers competing for work. When multiple consumer processes attach to the same queue, the broker hands each message to only one of them — the **'competing consumers'** pattern, used to parallelize work across a pool of workers. Once a message is consumed and acknowledged, it's gone from the queue for everyone. A **topic**, by contrast, is a publish/subscribe channel: every consumer that subscribes gets its own independent copy of every message published after it subscribed. Internally, most topic implementations achieve this either by maintaining one delivery queue per subscriber, or — in log-based brokers — by having each subscriber track its own read offset into a shared, retained log, so multiple readers can independently lag or replay without affecting each other. ## Why both models exist These two models exist because they answer different questions. | Model | The question it answers | The primitive | |---|---|---| | Queues | 'how do I distribute a stream of work across a pool of workers so nobody idles and nobody duplicates work?' | a load-balancing primitive | | Topics | 'how do I notify every interested party that something happened, without the publisher needing to know who they are?' | a fan-out primitive | An order-placed event might need to reach an email service, an inventory service, and an analytics pipeline — three independent consumers doing unrelated work off the same event; that's a topic. Resizing ten thousand uploaded images is one unit of work that should be picked up once by whichever worker is free; that's a queue. ## What each gives up - **Queues** give natural load balancing and back-pressure, but make it hard for two different services to independently receive the same events without a fan-out layer in front. - **Topics** give decoupled, add-a-subscriber-anytime broadcast, but if you also want load-balanced parallel processing within one subscriber's own logic, you need multiple worker threads pulling from that subscriber's local buffer, or a hybrid model with consumer groups and partitions. A widely used pattern is **fan-out-to-queue**: a topic broadcasts to several queues (one per downstream system), and each queue then supports competing consumers within that system — getting both broadcast and parallel processing at once (e.g., Amazon SNS fanning out to multiple SQS queues). ## Failure modes - **The classic mistake** is putting competing consumers on what should be a topic: only one service ends up receiving each event and the others silently starve, with no error — just missing downstream data that's easy to miss until someone notices numbers don't add up. - **The inverse mistake** is fanning a work queue out as if it were pub/sub: every worker processes every task redundantly, causing duplicate side effects (e.g., charging a card three times). - **Head-of-line blocking.** Another queue failure mode is a poison message at the front of a strict FIFO queue, which can block everything behind it unless the broker supports skipping to a dead-letter destination. - **Outside the retention window.** For topics, a subscriber offline too long can fall outside the retention window and permanently miss messages, silently, unless it notices a gap in sequence numbers. ## How two products spell it - **RabbitMQ** makes the distinction explicit: you declare a queue, and separately declare an exchange (the routing layer) that can fan out to one or many queues; a 'fanout exchange' bound to three queues gives topic-like broadcast, while consumers attached to any single queue compete for its messages. - **Kafka** instead exposes one abstraction — the partitioned topic — and gets queue-like semantics via consumer groups: each partition is delivered to exactly one consumer per group (queue-style), while every distinct consumer group reads the entire topic independently (topic-style). Recognizing which model a given broker product uses is essential before designing a multi-consumer system on top of it.