Queue full (503): rejecting requests to stay alive
A bounded queue is a deliberate limit: when it is full, new requests are rejected immediately with 503 Service Unavailable instead of waiting forever.
What causes it
Rejecting is a symptom of overload, not its cause. Requests arrive faster than the component can serve them, the waiting line fills, and the limit kicks in. That is usually better than the alternative — an unbounded queue that grows until memory runs out and the whole server crashes. Load shedding keeps the requests that are accepted fast.
How to recognise it
- 503 responses while latency of successful requests stays reasonable
- Queue depth pinned at its maximum
- Utilisation at or above 100%
The math
Rejected rate ≈ arrival rate − capacity (when ρ = λ / cμ ≥ 1)
Error messages you will see
| Error | Seen in |
|---|---|
503 Service Unavailable | Users, Router, Server, Database, Cache, Queue and 212 more |
es_rejected_execution_exception | Elasticsearch, OpenSearch, Amazon OpenSearch Service |
How to fix it
- Add capacity (more instances, cores or threads)
- Shed or rate-limit load upstream
- Make each request cheaper
Reproduce it in the simulator
Open the simulator, build a small architecture and use Fault injection in the inspector, or push traffic past a component’s capacity.
Learn more
Part of the guide Load balancing and capacity planning.