Message Extraction: Pull versus Push

Why this matters: the requirements say consumers "retrieve messages." That verb hides a real design decision — does the consumer ask, or does the broker send? The answer determines who controls the rate, and rate control is what keeps the system from collapsing.

Key takeaway

Two models. In pull, the consumer requests messages when it is ready. In push, the broker delivers as soon as messages arrive. The difference is who decides the delivery rate — and that decides who absorbs an overload.

The two models

	Pull	Push
Who initiates	The consumer, when it has capacity	The broker, when a message arrives
Rate is controlled by	The consumer	The producer, indirectly
Latency when idle	Up to one poll interval	Immediate
Cost when idle	Wasted empty polls	None
Behavior under overload	Consumer simply asks for less; backlog stays in the queue	Broker overwhelms the consumer unless flow control is added
Batching	Natural — ask for 100 at a time	Requires explicit support
Consumer must be	Nothing special — can sit behind a firewall or NAT	Addressable by the broker

Pull, and the polling problem

The naive pull implementation is short polling: the consumer asks repeatedly on a fixed interval.

Consumer:  any messages?  -> no
           (wait 1s)
           any messages?  -> no
           (wait 1s)
           any messages?  -> yes, here are 3

This trades two bad properties against each other with one dial:

Short interval → low latency, but most polls return empty — wasted requests, wasted broker CPU, wasted money on a metered service.
Long interval → few wasted polls, but a message can sit up to one full interval before anyone looks at it.

Long polling removes the trade almost entirely. The consumer's request blocks at the broker until either a message arrives or a timeout expires:

Consumer:  any messages? (I'll wait up to 20s)
Broker:    ...holds the connection...
           message arrives -> returns immediately

Why push is harder than it looks

Push sounds strictly better — no polling, no wasted requests, immediate delivery. The problem shows up under load.

Push has no natural backpressure

If the broker sends messages as fast as they arrive, and the consumer processes more slowly, the mismatch has nowhere to go. The messages are already in flight. The consumer's buffers fill, then it starts dropping, timing out, or running out of memory.

The queue was supposed to be the buffer. Under push, part of the backlog silently relocates into the consumer — the one component least equipped to hold it, because it has no durability.

Fixing this means adding flow control: the consumer advertises how much it can take (a prefetch count or credit limit), and the broker respects it. RabbitMQ calls this the prefetch count, and tuning it is a standard operational chore precisely because getting it wrong causes exactly this failure.

But notice what flow control is: the consumer telling the broker how much to send. That is pull, re-implemented on top of push. The pull model gets it for free.

What real systems chose

System	Model	Notes
Apache Kafka	Pull	Consumers fetch batches at their own pace and track their own offset. The design document explicitly argues that pull avoids overwhelming consumers and makes batching natural
Amazon SQS	Pull	`ReceiveMessage` with long polling up to 20 seconds
RabbitMQ	Push (with pull available)	Delivers to subscribed consumers, bounded by a prefetch count for flow control. A `basic.get` pull API exists but is discouraged for throughput

Choosing

Choose	When
Pull with long polling	The default. High throughput, variable consumer speed, consumers that autoscale, or many consumers. You get flow control and batching for free
Push	Low, predictable message rates where latency matters more than throughput, consumers are few and stable, and you are willing to configure prefetch limits
Push to an endpoint (webhooks, SQS→Lambda)	The consumer is serverless or event-triggered and has no process sitting there to poll. The platform absorbs the flow-control problem for you

Key takeaway

Pull with long polling is the default for good reason: the consumer keeps control of the rate, batching is natural, and push's latency advantage largely disappears. Push needs explicit flow control — which is pull, reimplemented — and forces the broker to hold per-consumer state.

Interview signal by level

Level	What a strong answer sounds like
L4	"Consumers read messages off the queue."
L5	Names the models and picks one: "pull, with long polling so we're not burning requests on empty responses but still get near-immediate delivery."
Staff+	Argues from backpressure: "pull, because the consumer controls the rate — under push an overload relocates the backlog into the consumer, which has no durability. Push needs prefetch limits, and a prefetch limit is just pull reimplemented. Pull also batches naturally, which matters more than it sounds: per-message overhead dominates when the work per message is small."

Next: the architecture.