Problem
Fast producer overwhelms slow consumer. Buffers fill, memory explodes, latency spikes, OOM kills.
resilienceestablished · low operational burden
Backpressure
Also known as: flow-control, reactive-streams, backpressure-pattern
Intent
Signal upstream to slow down when downstream cannot keep up, preventing buffer overflow and cascade failure.
Forces
- •Producer rate varies, consumer rate varies
- •Unbounded buffers = memory exhaustion
- •Dropping data may be unacceptable
- •Need explicit flow control, not implicit buffering
Solution
✓ When to Use
- •Streaming data: logs, metrics, events, file uploads
- •Async pipelines with variable throughput
- •Reactive systems (Project Reactor, RxJava, Akka Streams)
✗ When Not to Use
- •Request-response (synchronous, natural backpressure)
- •Low throughput where buffering is fine
- •Fire-and-forget (no consumer to signal)
Pros
- +Prevents OOM, buffer bloat, cascade failure
- +Explicit flow control: consumer drives pace
- +Enables elastic scaling: slow consumer = backpressure upstream
Cons
- −Complexity: must propagate through entire chain
- −Latency: waiting for credits adds delay
- −Deadlock risk: circular dependencies in flow control
- −Not all protocols support it (HTTP/1.1 limited)
Cost Profile
Infrastructure
None — protocol/logic level
Operational
Low — monitor queue depths, credit starvation
Cognitive
Medium — reactive thinking, flow control
Failure Modes
Credit leak: consumer forgets to renew → producer stalls
Unbounded buffer somewhere in chain → OOM
Priority inversion: low-priority blocks high-priority
Circular backpressure: A waits for B, B waits for A
Real-World Examples
Alternatives
- bounded-queue
- rate-limiting
- load-shedding
- circuit-breaker
Related Patterns
- rate-limiting
- circuit-breaker
- load-shedding
- bounded-queue
- reactive-streams
Competency Domains
distribution communicationreliability opsdata stateeconomics evolution