Consumer Patterns

A few shapes solve most problems

By now you know the mechanics — exchanges, queues, bindings, acks. This module is about the recurring shapes you assemble them into. Almost every real RabbitMQ system is one of a small number of patterns, or a combination of them.

The key distinction to hold onto: do you want work shared or broadcast?

Shared — many workers pull from one queue and each message goes to exactly one of them. That’s a work queue (competing consumers). It scales throughput.
Broadcast — each subscriber has its own queue and every subscriber gets a copy. That’s publish/subscribe. It fans an event out to independent reactions.

Get that fork in the road right and the rest is detail.

What this module covers

Lesson	The pattern
Work queues	Distribute tasks across competing workers on one shared queue
Publish/subscribe	Broadcast one event to many independent consumers, each with its own queue
RPC over RabbitMQ	Request/reply with `correlation_id` and `reply_to` — and when not to
Retry & backoff	Handle failures without tight poison-message loops

The shared-vs-broadcast fork

flowchart TB
  subgraph wq["Work queue — shared"]
    x1["exchange"] --> q1["one queue"]
    q1 --> w1["worker A"]
    q1 --> w2["worker B"]
  end
  subgraph ps["Pub/Sub — broadcast"]
    x2["fanout exchange"] --> qa["queue A"] --> sa["subscriber A"]
    x2 --> qb["queue B"] --> sb["subscriber B"]
  end

One queue shared by workers, versus a queue per subscriber

In a work queue, adding a worker means more throughput on the same stream of tasks. In pub/sub, adding a subscriber means another independent reaction to the same events. Same broker, opposite intent — decided entirely by whether consumers share a queue or each hold their own.