Backpressure
A slow consumer signalling upstream to slow down, instead of silently accumulating work.
When a producer outpaces a consumer, the work has to go somewhere. Backpressure makes that visible: the consumer refuses or delays new work so the producer slows down. Without it, the queue grows until memory runs out or latency becomes meaningless — and the failure appears far from its cause.
Full guide:
HTTP 429 rate limits: how long to wait, and which limit is binding
— Honour Retry-After if the response carries one, and otherwise back off exponentially with jitter. A 429 means the request was understood and refused for pacing, so nothing was processed and the identical request is safe to retry once the wait has elapsed. Retrying immediately is the one response that reliably makes things worse.
Key facts
- An unbounded queue does not remove the limit, it converts a fast visible failure into a slow invisible one.
- A rate limit is backpressure expressed over HTTP: 429 is the server telling a client to slow down.
- Latency under sustained overload grows without bound while throughput stays flat, so queue depth warns earlier than response time.
- Dropping work can be the correct response when it is stale — a delayed metric or an expired request may be worth less than the capacity to accept new ones.
Frequently asked questions
Should I just make the queue bigger?
Only to absorb bursts. If the consumer is persistently slower than the producer, a bigger queue delays the failure and makes it worse — every item added is latency someone eventually experiences.
What should I monitor?
Queue depth and its rate of change, not just latency. A queue that is growing steadily tells you about the failure minutes before response times do.
Machine-readable copy of this page:
/glossary/backpressure.md