Backpressure
When you can't keep up, tell upstream to slow down instead of collapsing.
By the end of this lesson, apply backpressure so overload degrades gracefully rather than catastrophically.
Backpressure is flow control: when a consumer can't keep up, it signals upstream to slow down or stop, rather than silently buffering forever. It's the difference between a system that degrades gracefully under overload and one that accumulates an unbounded queue and then falls over.
Signal upstream, not buffer forever
- A consumer at capacity signals the producer to slow (or returns 429), uses a bounded queue, and sheds excess load rather than buffering without limit.
flowchart LR up[Producer] -->|slow down / 429| down[Consumer at capacity] down -->|bounded queue| work[Work] down -->|reject excess| shed[Load shed]
Mechanisms: bounded queues (reject when full), blocking/pull-based streams (consumer pulls at its own rate), explicit slow-down signals (HTTP 429 with Retry-After, TCP flow control), and load shedding (drop or reject low-priority work to protect the core). The key mindset: it is better to reject some requests cleanly than to accept all and fail everything.
This is where the abstraction starts leaking.
An unbounded in-memory queue feels like it 'absorbs' load. It's actually deferring collapse: latency climbs invisibly, then memory runs out. A queue without backpressure is a slow-motion outage.
Backpressure sacrifices some throughput/acceptance (you reject or slow requests) to protect latency and stability for the requests you do accept. Buffering everything optimizes acceptance right up to the point of total failure.
Why is returning 429 sometimes healthier than accepting every request?
Accepting beyond capacity builds an unbounded backlog and eventually fails everything; shedding excess keeps the accepted work fast and the system alive.