Backpressure in Practice (Push vs Pull, Bounded Queues)

Backpressure regulates data flow between producers and consumers to prevent overload. This lesson explains pull-based flow control, bounded queues, reactive streams, and practical production patterns for safe throughput management.

On this page

Backpressure in Practice: Controlling Flow Instead of Collapsing Under It

Backpressure is the mechanism by which a system signals upstream components to slow down when downstream capacity is limited. Unlike load shedding, which rejects excess work, backpressure attempts to regulate flow so that overload does not occur in the first place.

In distributed systems, uncontrolled producers can overwhelm consumers, queues, or storage layers. Backpressure introduces feedback.

The Core Problem: Unbounded Flow

Without flow control:

Producers generate events at maximum rate.
Consumer processing lags behind.
Queues grow unbounded.
Memory pressure increases.
Latency becomes unpredictable.

Eventually, the system fails due to resource exhaustion.

Push vs Pull Models

Push-Based Systems

Producers send data without explicit demand signals from consumers. This model requires explicit backpressure controls to avoid overload.

Pull-Based Systems

Consumers request data when ready. Flow naturally matches processing capacity.

Pull-based systems inherently support backpressure more safely.

Bounded Queues

The simplest form of backpressure is a bounded queue.

if queue_size >= max_capacity:
    block_or_reject()

Bounded queues prevent unbounded memory growth. When full, they either block producers or reject new work.

Blocking vs Dropping

Blocking: Slow producers when queue is full.
Dropping: Discard excess messages.

Blocking is safer when data integrity matters. Dropping may be acceptable for non-critical telemetry.

Producer Throttling

In messaging systems, brokers may throttle producers when consumers lag excessively.

Throttling mechanisms include:

Limiting publish rate
Reducing batch size
Applying dynamic quotas

This prevents write amplification during consumer slowdown.

Production Scenario: Memory Explosion in Event Processor

Symptom

Event processor crashes with out-of-memory errors under sustained load.

Root Cause

Consumer reads messages faster than it can process. Internal queue is unbounded. Memory grows until exhaustion.

Diagnosis

Queue depth increasing steadily.
GC frequency rising.
No flow control between ingestion and processing layers.

Resolution

Introduce bounded internal queue.
Pause consumption when queue reaches threshold.
Implement producer throttling.

Backpressure in Messaging Systems

In stream processing systems, backpressure propagates via:

Consumer lag metrics
Offset commit delays
Broker-side throttling
Flow control signals in reactive APIs

When properly configured, slow consumers naturally limit upstream throughput.

Reactive Streams Model

Reactive streams frameworks implement explicit demand signals.

subscriber.request(n)

Producer emits only when demand exists. This provides fine-grained flow control.

Interaction with Other Patterns

Retries: Must respect backpressure to avoid amplification.
Load shedding: Applies when backpressure cannot regulate sufficiently.
Bulkheads: Prevent backpressure from spreading across workloads.
Timeouts: Ensure blocked operations release resources.

Backpressure is preventative; load shedding is reactive.

Choosing Backpressure Signals

Common triggers include:

Queue length thresholds
Consumer lag exceeding SLO
CPU utilization above safe limit
Memory pressure signals
Thread pool saturation

Signals should reflect true resource constraints.

Observability Requirements

Queue depth metrics
Consumer lag trends
Producer throughput
Memory usage patterns
Processing latency percentiles

Without observability, backpressure tuning becomes guesswork.

Failure Injection Test

# Backpressure validation
1) Generate sustained high input rate
2) Slow down consumer processing artificially
3) Observe queue growth and backpressure activation
4) Verify producer throughput decreases
5) Confirm system stabilizes without crashing

Common Anti-Patterns

Unbounded internal queues
Ignoring consumer lag metrics
Retrying immediately despite backpressure
No producer throttling mechanism
Blocking critical threads indefinitely

Operational Checklist

Are all queues bounded?
Is producer throttling implemented?
Are backpressure triggers clearly defined?
Are lag metrics tied to alerting?
Is load shedding configured as a fallback?

Key Takeaways

Backpressure regulates flow to prevent overload.
Bounded queues are fundamental safety controls.
Producer throttling stabilizes downstream systems.
Reactive demand signaling provides precise control.
Backpressure integrates with retries and load shedding.

Backpressure is the discipline of respecting downstream capacity. In production systems, sustainable throughput depends not on maximum speed, but on controlled flow.

← Load Shedding (Fail Small, Not Catastrophically)

Graceful Degradation (Feature Flags and Partial Responses) →