Backpressure

Backpressure is a flow control mechanism: when a consumer cannot keep up with the rate of incoming data, it signals the producer to slow down. Without backpressure, a fast producer overwhelms a slow consumer — memory fills up, the process crashes, and the system fails. In reactive programming (RxJava, Project Reactor) and streaming systems (Kafka, gRPC streams), backpressure is a first-class concept. TCP itself implements backpressure through its flow control window. In system design, backpressure prevents the "fast producer, slow consumer" problem that causes outages.

Why This Matters

Without backpressure, a microservice that receives 10,000 messages/sec but can only process 5,000 will buffer the excess in memory. Within minutes, the heap fills, garbage collection pauses spike, latency increases, and the service crashes. Now the backlog is larger and the recovering service faces an even bigger wave. This cascading pattern is one of the most common causes of distributed system outages. Backpressure breaks this cycle by telling the producer: slow down, I cannot keep up.

The Building Blocks

• Bounded Buffers: Limit the queue size. When the buffer is full, the producer blocks or drops messages. This is the simplest form of backpressure — memory is bounded by design.
• Rate Limiting at Source: The consumer publishes its current processing rate, and the producer throttles to match. Pull-based consumers (Kafka) naturally achieve this by only fetching what they can handle.
• Credit-Based Flow Control: The consumer sends credits (permits) to the producer. The producer can only send as many messages as it has credits. Used in AMQP and Reactive Streams (Java).
• TCP Flow Control Window: TCP's receive window is backpressure at the transport layer. When the receiver's buffer is full, it advertises a zero window, causing the sender to pause.
• Load Shedding: When backpressure is insufficient, the system drops excess work intentionally — returning 503 or dropping low-priority messages to protect high-priority traffic.

Under the Hood

In a Kafka consumer group, backpressure works naturally: consumers poll for messages at their own pace. If a consumer slows down, its partition lag increases but it does not crash — it simply falls behind. The producer continues publishing to the topic, and the broker stores messages on disk. The consumer catches up when it recovers capacity. This pull-based model is inherently backpressure-aware.

In reactive programming (RxJava, Project Reactor), backpressure is explicit. A Subscriber requests N items from the Publisher. The Publisher sends at most N items and waits for more requests. If the Subscriber is slow, it requests fewer items, and the Publisher naturally throttles. Strategies for when the buffer is full include: drop newest, drop oldest, buffer with timeout, or signal an error.

In gRPC bidirectional streaming, HTTP/2 flow control provides backpressure. Each stream has a flow control window (default 64KB). When the receiver has not consumed the window, the sender blocks. This prevents a fast server from overwhelming a slow client.

How Companies Actually Do This

Netflix uses reactive streams with Project Reactor for their API gateway. When downstream services slow down, backpressure propagates through the reactive pipeline, preventing the gateway from accepting more requests than it can handle.

Kafka ecosystem provides natural backpressure through consumer-driven polling. Uber's Kafka pipelines process trillions of messages daily — consumer lag dashboards alert when consumers fall behind, triggering scaling.

Node.js streams implement backpressure via the readable/writable stream contract. When pipe() connects a fast reader to a slow writer, the readable stream pauses automatically until the writable stream drains.

Common Pitfalls

1. Using unbounded in-memory queues between producers and consumers — works in testing, OOMs in production when the consumer slows down
2. Applying backpressure at the wrong layer — throttling the HTTP load balancer when the real bottleneck is a slow database query three services deep
3. Not monitoring consumer lag — backpressure only works if you can detect when consumers are falling behind, otherwise you discover the problem when the system crashes

Interview Questions Worth Practicing

1. How would you handle a situation where a microservice receives 10x more messages than it can process?
2. What is the relationship between backpressure and TCP flow control?
3. When would you choose to drop messages versus slow down the producer?

The Tradeoffs

• Throughput vs Stability: Backpressure reduces overall throughput by slowing the producer, but prevents crashes and cascading failures. Without it, you get higher throughput until the system collapses.
• Buffering vs Dropping: Bounded buffers absorb temporary spikes but add latency. Dropping excess messages maintains latency but loses data. The right choice depends on whether data loss is acceptable.
• Push vs Pull: Push-based systems need explicit backpressure mechanisms (credit-based, bounded buffers). Pull-based systems (Kafka consumers) have natural backpressure but may increase end-to-end latency.

How to Explain This in an Interview

Here is how I would explain Backpressure in a system design interview:

Backpressure is how a slow consumer tells a fast producer to slow down. Without it, the consumer's buffer fills up and the process crashes. I would explain three approaches: bounded buffers (simplest — when the queue hits 10,000, block the producer), pull-based consumption (like Kafka — the consumer only fetches what it can handle), and credit-based flow control (like Reactive Streams — the consumer grants permits to the producer). The key insight is that TCP itself implements backpressure via the receive window. In a system design, I would use Kafka for inter-service messaging (natural backpressure) and bounded in-memory queues for in-process pipelines. I would monitor consumer lag and auto-scale consumers when lag exceeds a threshold.

Related Topics

• Message Queues
• Pub/Sub
• Rate Limiting
• Circuit Breaker

Original DosiBridge notes for Backpressure

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Backpressure is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• SLO: For Backpressure, decide the SLO before choosing tools; otherwise the design looks clean but fails when backpressure changes.
• Capacity Headroom: For Backpressure, decide the capacity headroom before choosing tools; otherwise the design looks clean but fails when backpressure changes.
• Failure Mode: For Backpressure, decide the failure mode before choosing tools; otherwise the design looks clean but fails when backpressure changes.
• Degradation Path: For Backpressure, decide the degradation path before choosing tools; otherwise the design looks clean but fails when backpressure changes.
• Operator Signal: For Backpressure, decide the operator signal before choosing tools; otherwise the design looks clean but fails when backpressure changes.

Production review question

If a team adopts Backpressure, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track backpressure health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Backpressure, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.