Some messaging systems have the broker push messages to consumers, while others have consumers pull (poll) messages from the broker. How do these two models differ in how they handle a consumer that's overwhelmed, and why do most high-throughput systems favor pull?

## Who initiates each message The mechanism difference is about who initiates transfer of each message and therefore who controls its pace. | Model | How the transfer works | |---|---| | **Push** | In a push model, the broker maintains an open connection or subscription to each consumer and actively sends messages as soon as they're available (or as soon as the broker decides to send them), without the consumer having to ask. Classic examples include traditional AMQP-style brokers (like RabbitMQ) in their default consume mode, and webhook-style delivery where the sender initiates an HTTP POST to the receiver. | | **Pull** | In a pull model, the consumer periodically calls a fetch/poll operation, explicitly requesting the next chunk of messages, and the broker only responds to that specific request — it never sends anything the consumer didn't ask for. Kafka is the canonical pull-based example: consumers repeatedly call a `poll()`-style method, specifying how many messages or how much data they're willing to receive, and the broker returns up to that amount from the offset the consumer is at. | ## Where rate-control lives The reason this distinction exists, and matters enormously, is that it determines where rate-control naturally lives. - **In push**, the sender (broker) is the one deciding the rate, but the sender generally doesn't know the receiver's real-time capacity — it knows the message is ready to go, not whether the consumer's CPU, memory, or downstream dependency can absorb it right now. That mismatch is exactly the back-pressure problem from before, but now happening at the transport/protocol layer instead of just the application/business layer: if push keeps firing messages at a consumer that's falling behind, messages queue up somewhere (in-memory buffers on the consumer side, unacknowledged in-flight counters on the broker side, TCP socket buffers) with the same risks — memory exhaustion, dropped connections, or unbounded unacknowledged message counts. - **In pull**, the consumer is structurally the one deciding the rate: it only issues the next poll when it's ready, so a consumer that's overwhelmed simply doesn't call poll again until it's caught up, and the broker is never in a position to force-feed it more than requested. This is why pull-based back-pressure is often described as "free" or "implicit" — it falls directly out of the request/response shape of the protocol rather than needing a bolted-on flow-control extension. ## The trade-off runs both ways The trade-off is not one-directional, though. - Push systems that want to avoid overwhelming consumers typically add explicit **flow-control mechanisms** to compensate — AMQP's QoS/prefetch-count setting caps how many unacknowledged messages the broker will have in flight to a given consumer at once, effectively converting push into a bounded, credit-based push that behaves similarly to pull once tuned correctly. - Pure pull's own cost is **latency and polling overhead**: because the consumer only discovers new messages on its next poll call, there's an inherent delay between a message being produced and a consumer noticing it, bounded by how frequently it polls; poll too rarely and you add latency, poll too aggressively when there's nothing new and you waste network round-trips and add needless load on the broker for empty responses. - Many pull-based systems mitigate this with **long-polling** — the broker holds the connection open and only responds once data is available or a timeout elapses — which gets close to push-like low latency while keeping the consumer-initiated, rate-controlling shape of pull. ## Failure modes Failure modes differ correspondingly. - **A push system without adequate flow control** shows up as a consumer's process suddenly getting slammed — its receive buffer or in-memory queue balloons, garbage collection pressure spikes, and in the worst case the consumer process crashes from memory exhaustion or the broker's connection to it drops, at which point in-flight unacknowledged messages typically get redelivered to someone else — potentially worsening a cascading overload if the whole fleet is under load simultaneously. - **A pull system's failure mode is subtler**: a consumer that's polling too infrequently (misconfigured poll interval, or blocked on a slow downstream call between polls) looks identical, from a lag perspective, to a consumer that's just slow at processing — you see lag grow either way, and diagnosing whether the bottleneck is "processing time per message" versus "time between poll calls" requires separate metrics (processing latency vs. poll interval/fetch size) rather than lag alone. ## A concrete comparison A concrete comparison: Kafka's pull model lets a single broker serve thousands of consumers each polling at whatever rate matches their own processing capacity, without the broker needing to track per-consumer send-rate state — that scalability characteristic is a major reason Kafka favors pull for its high-throughput, log-based use case. By contrast, RabbitMQ's default push behavior, tuned with a `prefetch_count` of, say, 10, means the broker will push up to 10 unacknowledged messages to a given consumer and then stop pushing more until acks bring that count back down — effectively a credit-based hybrid that gets RabbitMQ's low per-message latency advantage from push while still bounding how far a slow consumer can fall behind on in-flight work before push traffic to it pauses.