"Every performance problem starts with a queue backing up somewhere": a socket listen queue, the OS run queue, a database I/O queue. An **unbounded** queue consumes all memory, and by Little's law, as its length heads toward infinity so does response time. So queues must be **finite** for response times to be finite. But a bounded, full queue forces a choice when a producer pushes one more item. The only options: pretend to accept it but drop it, accept it and drop something older, refuse it, or **block the producer**. Blocking is flow control — it applies **back pressure** that propagates upstream, throttling the ultimate client until the queue drains. TCP does exactly this with its window: once full, the sender can't send, its transmit buffers fill, and `write()` blocks. Nygard's example: an API server allowed 100 simultaneous calls to its storage engine; the 101st call's thread blocks until a slot frees; that blocking *is* the back pressure, so the server can't outrun the engine. Constraints: back pressure works **within a system boundary** and only when the consumer pool is **finite** (a diverse Internet "upstream" has no systemic throttle). Since it inevitably blocks threads ("a quick path to downtime"), at the edges you need load shedding and async calls instead (accept on one thread pool, call out on another, time out to a 503 or queue to a 202). Distinguish temporary back pressure from a genuinely broken consumer, and alert monitoring when it kicks in. "The only alternative is to let them crash the provider." --- *Source: [[Release It Second Edition]] (Michael T. Nygard, Pragmatic Bookshelf 2018) — Ch 5 — Stability Patterns*