Server
Backpressure
Backpressure is a server pushing back on callers when its queue is full, so work slows at the source instead of piling up inside. It shows up as refusals, delays or blocked writes rather than as silent growth.
How it is measured
Look for the signals that a limit has been reached: a bounded queue length, rejected requests, a TCP window that shrinks, or a producer blocked on a write. The number that matters is the queue depth against its cap, sampled every few seconds.
A healthy system with backpressure shows queue depth bouncing under a ceiling with some 429 or 503 responses. A system without it shows memory growing, latency climbing past every timeout, and then a crash.
Worked example
A WordPress site runs an image-resize queue capped at 200 jobs. An editor bulk-uploads 1,500 photos. Job 201 is refused with a 'try later' response, and the upload tool backs off to a trickle of 20 a minute while workers drain the queue.
Without the cap the queue would hold all 1,500, workers would run out of RAM at job 900, and the whole admin would hang. The refusals felt annoying, but they were what kept the site up.
How it differs
Backpressure is the server telling callers to wait because it is full. Saturation is the state of being full, and backpressure is one response to it. Backpressure excludes the unbounded queue that quietly absorbs everything. Saturation excludes any statement about what the system does next.
Common errors
Making every queue unbounded so nothing is ever refused. Retrying a refusal immediately and making it worse. Treating a 503 under load as a bug rather than the system working as designed. Applying limits only at the edge while internal queues stay open. Not telling callers how long to wait.
In practice
Find the one queue in your stack with no cap, usually a job queue or an in-memory buffer, and give it one. Return a Retry-After value on refusals so clients know how long to sleep. Watch queue depth alongside memory for a week.