Backpressure

In technical terms

Reactive Streams formalizes it (bounded request(n) credit between subscriber and publisher); brokers and protocols implement equivalents. Unacked-message limits, consumer prefetch ceilings, TCP flow control, HTTP/2 window updates, and 429/Retry-After at API edges.

Why it appears in interviews

Design questions about bursts (notification fan-out, click pipelines, log shippers) use it to separate demo builders from operators: a queue does not remove backpressure, it converts it into growing latency or memory. The interviewer waits for you to name what happens at 40 minutes into the spike.

The common misconception

“Add a queue” as the end of the answer. It only decides where pressure accumulates. And “drop old messages” as the only alternative to crashing: TTL policies, sampling, priority drains, and shedding non-critical classes are the middle ground.

Trade-offs & when it hurts

Propagating pressure honestly slows producers. Users feel it as latency or 429s; absorbing in the queue trades freshness for survival with an explicit lag budget; dropping trades completeness for availability. The passing answer states which pain the product chose and what is measured to notice it was wrong.

How to show it in an interview

The moment a queue enters your design, add the pressure line: “Consumers pull with a bounded prefetch and the broker caps unacked messages, so a 2x spike becomes 30 seconds of added lag before it becomes shed events. Queue age is the metric I page on.” That single sentence converts a diagram into an operated system.

Questions this concept earns

• A log shipper runs 2x slower than producers all day. Walk the options and choose one.
• The consumer dies for 10 minutes: where does the backlog live, and what happens when it drains?
• Which events can you drop under pressure: and how do you tell the product that you did?

Related