Publish/Subscribe mit Fanout-Exchanges

Work queues deliver each message to one worker. But sometimes every interested consumer needs the same message — like broadcasting a live score to all dashboards.

This is the publish/subscribe pattern.

Pub/sub in RabbitMQ uses a fanout exchange, which copies every incoming message to all queues bound to it, ignoring routing keys entirely.

A producer declares the fanout exchange and publishes to it.

Notice the routing key is an empty string. Fanout exchanges ignore it, so producers do not need to specify any routing logic at all.

Each subscriber usually wants a fresh, private queue. Declaring a queue with no name lets RabbitMQ generate a random one, and marking it exclusive auto-deletes it when the consumer disconnects.

The subscriber binds its temporary queue to the fanout exchange so it begins receiving broadcasts.

Because each subscriber has its own queue, they all get independent copies of every message. Adding a new subscriber does not affect the others.

Key difference:

• Work queue — one queue, many workers, each message handled once
• Pub/sub — many queues, each subscriber gets every message

Fanout pub/sub fits:

• Live notifications and dashboards
• Cache invalidation across many nodes
• Broadcasting configuration changes
• Logging to multiple sinks

If no queue is bound to a fanout exchange when a message arrives, the message is simply discarded. Fanout does not store anything itself — queues do.

To scale pub/sub, just add more subscribers, each with its own temporary queue bound to the exchange. The fanout exchange handles fan-out automatically.

You learned the publish/subscribe pattern:

• Fanout exchanges broadcast to all bound queues
• The routing key is ignored
• Subscribers use temporary exclusive queues
• Each subscriber gets an independent copy of every message

This pattern is the foundation for notifications, cache invalidation, and live updates.