Back-pressure & Flow Control — Why Systems Must Push Back

L0 · Back-pressure is the signal a slow consumer sends a fast producer to block, slow, or shed — without it, the speed mismatch just accumulates in an unbounded buffer until memory or latency runs out.

L1 · ② Failure — "A downstream dependency starts timing out under load. Your service queues the calls instead of rejecting them, 'so we never drop a customer request.' Twenty minutes later the box OOMs and takes the whole service down. What's the actual fix?"
Trap: "Just make the buffer bigger so we never have to drop a request." — A bigger unbounded queue doesn't remove the overload, it hides it: memory keeps climbing and latency creeps up invisibly until the crash, which now takes longer to diagnose because nothing looked wrong five minutes earlier.
Bar: Bound the queue and make its "full" state an explicit decision: either block the caller (so the mismatch is visible one hop upstream) or reject fast (503/429) once depth exceeds a cap. An unbounded queue is bufferbloat by another name — it converts a fast, alertable failure into a slow, silent one that ends in the same OOM anyway. circuit breaker / designing for failure

L2 · ① Concurrency — "Good, you bounded the queue. But the producer is your own request-handling thread pool, and it blocks on offer() whenever the queue is full. Under sustained load, every worker thread ends up parked on that internal queue while user connections pile up at the load balancer. Did bounding actually fix anything?"
Trap: "Bounding the queue already solved it — it can't OOM anymore, so we're safe."
Bar: Bounding without propagation just relocates the same failure one hop upstream: an indefinite block on a full queue exhausts the thread pool exactly like an unbounded queue exhausts the heap. Real back-pressure has to travel to something that can actually shed or slow the true source — put a deadline on the enqueue call itself, and on timeout reject at the edge (gateway/load balancer) instead of parking a worker thread forever. thread pools & executors

L3 · ③ Scale — "Between two services you own, Reactive Streams' request(n) throttles beautifully. Now that same pipeline has to feed a third-party HTTP webhook consumer at 10x volume — plain HTTP has no credit protocol. How do you back-pressure across a boundary that can't say 'I'm full'?"
Trap: "Cap the outbound call rate at a fixed number per second and hope it roughly matches their capacity."
Bar: A static rate is a guess; you need a real feedback signal standing in for request(n) — the third party's 429/503 + Retry-After, or your own outbound queue's depth and age, adapted with an AIMD-style scheme (ease up on signals of overload, ramp up slowly on success) the same way TCP's congestion window infers capacity without an explicit grant. Kafka producers do exactly this: consumer lag is the feedback signal when there's no synchronous credit channel. Kafka producer back-pressure & consumer lag

L4 · ⑤ Adversary/Edge — "Your bounded queue rejects with 503 once depth crosses a threshold. An attacker (or a buggy internal client) profiles that threshold and fires bursts timed to always land just under it, holding connections open right at the edge. They stay 'compliant' with your published limit while pinning a disproportionate share of your capacity. Is your back-pressure enough?"
Trap: "We already shed load past the threshold — that's the defense, we're covered."
Bar: Global back-pressure protects the process from overload; it does nothing to stop one client from monopolizing the room left under the threshold. You need per-client isolation — separate bounded queues or a token bucket per tenant/key (bulkheading) — so one caller's burst can't starve the others; global shedding is the safety valve, per-key rate limiting is the fairness mechanism, and you need both. retry storms & load shedding

L5 · ⑥ Cost/Simplicity — "A staff engineer proposes: skip all this credit-propagation plumbing, just size every queue 10x bigger and put an alert on depth. Simpler, cheaper, fewer moving parts. Why not just do that?"
Trap: "Bigger buffers plus an alert are operationally simpler and cheaper than wiring back-pressure through every hop."
Bar: A bigger buffer trades a fast, visible failure for slow, invisible bufferbloat: by Little's Law, latency = queue depth ÷ throughput, so p99 degrades steadily long before the depth alert fires — users feel it minutes before anyone pages. Explicit bounding + shedding costs a little upfront design, but converts a silent latency death into a sharp, alertable signal (429/503 rate spike), which shrinks both blast radius and time-to-diagnose — cheaper in the metric that matters. queueing non-linearity & Little's Law

The floor keeps dropping: now push the same question across a network partition — the consumer that was supposed to say "I'm full" is simply unreachable. Do you fail open (accept and risk the overload you were trying to prevent) or fail closed (reject and lose availability)? You've left flow control and walked straight into CAP.

Self-locate: reached for "bigger buffer" at L1 → mid-level; caught that bounding without propagation just moves the failure (L2) and reasoned through per-tenant isolation (L4) and the bufferbloat cost trade-off (L5) → staff signal.

Facing any new concept? Hit it with the six: concurrent? failing? at 100×? over time? adversarial? worth the cost? — that's the interviewer's whole playbook.