We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Turn on a faucet and plug the drain. Water fills the sink. If the water comes in faster than it drains, the sink overflows. Obvious, right? The fix is equally obvious: turn down the faucet.
Now picture this in software. Your API receives 10,000 requests per second. Your database can handle 2,000 queries per second. Without any flow control, the system does one of two things: it queues 8,000 requests per second (queue grows forever, eventually OOM), or it drops 8,000 requests per second silently (data loss).
Back pressure is the engineering solution: when a downstream system is overwhelmed, it signals upstream to slow down. The database tells the application "I'm at capacity, stop sending." The application tells the "I can't take more, reject or redirect." The load balancer tells clients "slow down" with HTTP 429 or 503.
has done this since 1981. The receiver advertises a window size: "I can accept this many bytes." When the receiver's buffer fills, the window shrinks to zero. The sender stops transmitting. When the buffer drains, the window reopens. Forty-five years of reliable data transfer built on a single principle: tell the sender how fast you can go.
Every healthy system has back pressure. A system without back pressure is a time bomb. It works fine under normal load and catastrophically fails the moment load exceeds capacity.
Back pressure is the propagation of load signals from consumer to producer. When the consumer is slower than the producer, the system needs a mechanism to slow the producer down.
| Mechanism | How It Works | Example |
|---|---|---|
| Reject excess | Return 429/503 when at capacity | , load shedding |
| Bounded queues | Queue fills up, new items are rejected | with max-length, thread pool with bounded work queue |
| Flow control | Consumer tells producer how much it can accept | window size, Reactive Streams request(n) |
| Throttling | Limit the producer's send rate | API rate limits, connection pool limits |
| Sampling | Process a random subset, discard the rest | High-volume metrics collection, logging under load |
The critical distinction: Back pressure is not the same as dropping requests. Dropping is a last resort. Back pressure is a controlled signal: "slow down, I'll be ready for more soon." The producer respects this signal and adjusts its send rate.
Reactive Streams (the Java/Kotlin standard) made this explicit. The Subscriber calls request(n) to tell the Publisher exactly how many items it can handle. The publisher must not send more than n items. This is pull-based back pressure: the consumer controls the rate, not the producer.