Backpressure
Slow producers or shed work before queues and consumers become unstable.
2–5 minute refresher
Timeout→Backoff→Jitter→Retry budget→Circuit breaker→Load shedding
Demand exceeds drain rate → signal upstream before the buffer becomes the outage
30second
refresher
refresher
Backpressure communicates that downstream capacity is constrained so upstream components slow, buffer within bounds, or reject work. It turns overload into an explicit control decision.
What problem does it solve?
Without feedback, producers continue at full speed while queues grow, latency becomes unbounded, memory fills, and recovery work accumulates faster than consumers can drain it.
How it works
- Measure arrival rate, service rate, queue age, and saturation.
- Set finite buffer and concurrency limits.
- Propagate flow-control signals or reduce producer credits.
- Prioritize valuable work and reject or defer lower-priority load.
- Recover gradually so released backlog does not cause another overload wave.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Large buffer | Absorb longer bursts | High latency and expensive recovery |
| Producer blocking | Natural rate matching | Can spread stalls upstream |
| Load shedding | Protect critical work | Explicit rejected outcomes |
What happens if?
Consumers recover and drain the backlog at full speed
The burst can overload databases or external APIs and cause a second failure. Use controlled ramp-up, dependency-aware concurrency, and retry budgets.
Where it appears
- Reactive streams
- TCP flow control
- Kafka lag controls
- Queue admission limits
Senior interview modeWhy is an unbounded queue not a resilience mechanism?Show answer
Under sustained overload it converts rejection into ever-growing latency and resource use. Eventually it exhausts memory or creates a backlog too expensive to recover.