Auditable architecture · Unit 11 of 13
Admission lives where it sees the queue
A capacity limit does two different things that are easy to fuse into one. The first is backpressure: under overload, telling the client 'not now, retry' with a 503/429 and a Retry-After, instead of queueing without bound. The second is protecting a scarce resource —typically the database connection pool— by capping how many requests touch it at once. They are different functions: the first gives the client a signal; the second keeps an already-admitted spike from crushing the engine. An admission gate inside the application does the second well, and it's tempting to believe it therefore does the first. It doesn't.
By the end, you'll be able to
- Separate two functions conflated in 'admission control': client backpressure and scarce-resource protection.
- Locate why an in-application gate can't shed overload when the queue forms earlier, at the server.
Understand
A capacity limit does two different things that are easy to fuse into one. The first is backpressure: under overload, telling the client 'not now, retry' with a 503/429 and a Retry-After, instead of queueing without bound. The second is protecting a scarce resource —typically the database connection pool— by capping how many requests touch it at once. They are different functions: the first gives the client a signal; the second keeps an already-admitted spike from crushing the engine. An admission gate inside the application does the second well, and it's tempting to believe it therefore does the first. It doesn't.
The reason is where the queue forms. In a worker-pool deployment (for instance the runtime's worker mode, with a fixed number of long-lived processes), when offered load exceeds capacity the requests queue UPSTREAM —at the server, waiting for a free worker— before entering the application. The gate lives INSIDE the worker, downstream of that queue: it only sees a request once a worker has already picked it up, so it never sees the queued excess and can't reject it. The symptom is unmistakable: under overload the gate records zero rejections while observed latency climbs into seconds. Backpressure can only come from whoever sees the queue, and the queue lives at the edge —a reverse-proxy that rejects fast (503/429 without queueing) or the worker pool's own concurrency limit. The rule: admission that provides backpressure belongs at the edge; the application gate stays to protect the database from what already passed the edge.
See
See the system boundary
The boundary is where the system decides what enters; capacity backpressure is one more boundary decision —it lives where the queue is seen, not deep inside the application.
Do
Run the practice in your checkout and keep the output as evidence.
Verify
Show that you can apply the unit. Progress only advances once you pass the assessment.
Criteria assessed
- Tell backpressure (a signal to the client) apart from connection-pool protection (keeping a spike from crushing the engine), and say which layer provides each.
- Explain why a gate inside a worker records zero rejections under overload even as latency climbs into seconds.
Primary sources
Content verified: 2026-07-23