How do you bound and isolate the concurrency that one GraphQL document's resolvers can create?

## Where the concurrency comes from, quantitatively The executor is permitted to resolve the fields of a selection set at the same time, and every list multiplies that permission. Take a solar-array telemetry graph: a site has 214 strings, each string's type declares 37 fields, and a monitoring client selects all of them. If a meaningful fraction of those fields calls a backend, one HTTP request has authorised on the order of seven or eight thousand concurrent operations. Nothing in the protocol bounds that number, and nothing in the executor does either — the permission to overlap comes with no ceiling attached. This is what makes it a leadership question rather than an implementation detail. The ceiling is a choice somebody makes on purpose, and if nobody makes it, the answer is "whatever the runtime happens to allow", discovered during an incident. ## What actually saturates Almost never CPU. The resources that run out, roughly in the order they do: * **Connections to a downstream** — a pool of, say, 40 database connections is the real ceiling on concurrent reads, no matter how many resolvers are ready to run. * **The downstream's own capacity** — you can be perfectly healthy while making a dependency unhealthy, which is worse, because the failure is somebody else's dashboard. * **Threads or task slots**, if resolvers block rather than yielding. * **Memory**, when thousands of in-flight operations each retain a buffer. So "tune the resolver pool" is usually the wrong frame. The pool is not the resource; it is one gate in front of several different resources with different capacities. ## The blocking-pool deadlock, which is worth naming The sharpest failure mode in this area: a resolver runs on a pool thread, submits dependent work to *the same* fixed pool, and blocks waiting for it. Under enough concurrency every thread in the pool is occupied by a resolver waiting for a task that is sitting in that pool's queue behind it. Throughput does not degrade — it goes to zero, and the service looks alive while serving nothing. Any design where a task can wait on another task in the same bounded pool has this property; the fixes are to never block on same-pool work, to give nested work its own pool, or to make the resolvers non-blocking. ## Four places the bound can live, and what each one buys **Admission control at the edge.** Cap concurrent in-flight requests. Coarse, cheap, and the only control that protects you from "many small documents" as well as "one huge document". It bounds the multiplier's outermost factor. **A per-request ceiling.** A permit count each request's resolvers draw from, so no single document can occupy the whole server. Preserves fairness between a monitoring client's wide document and everyone else's small ones. The cost is that a legitimately wide request now takes longer, which is usually the correct trade. **Per-dependency bulkheads.** A separate bounded lane for each backing source. This is the highest-value control, because the failure it prevents is the expensive one: a single degraded dependency absorbing every unit of concurrency in the process and taking down fields that had nothing to do with it. When its lane is full, calls to that source queue briefly and then fail fast, and the rest of the graph keeps serving. **The downstream's own limits.** Connection pools and server-side rate limits are a real bound, but they are a backstop, not a plan — reaching them usually means queueing somewhere you cannot see. A related control is coalescing repeated fetches so the concurrency never gets created in the first place; that is the batching pattern's job and its own subject. Static limits on how expensive a document may be before execution starts are a third, different lever that belongs with abuse controls. Concurrency bounding is what remains once you have taken both: the load a *legitimate, already-admitted* document is allowed to generate. ## Deadlines and cancellation A bound that only queues work is half a design. If a client has already given up, or the request's deadline has passed, every still-queued call is pure waste that is also holding a permit. Propagate a deadline into resolvers and their downstream calls, and cancel outstanding sibling work when the response can no longer be delivered. This is also where you discover whether your executor abandons in-flight resolvers when a field error nulls their parent — some do, some do not, and "some do not" means abandoned work keeps consuming the very capacity you are trying to protect. ## Measuring the right things Request latency alone will not tell you where the ceiling is. Instrument **per-dependency in-flight count and queue wait**, **permit acquisition time** for each bulkhead, and **fan-out per request** — how many downstream calls one document produced. That last metric is the one that turns "the graph got slow" into "this one client's document changed shape last Tuesday". Alert on saturation of a lane, not on the aggregate. ## The tradeoff to own out loud More concurrency lowers the latency of a single request and raises the peak load a burst of requests puts on shared dependencies. Those pull in opposite directions, and there is no number that is right for both. The honest position is that the ceiling is set against the weakest dependency's measured capacity, not against a latency target; that different lanes get different ceilings because the sources have different capacities; and that a mostly-sequential mode is a legitimate, predictable configuration for a graph whose backends are fragile. The failure to avoid is the one that looks like tuning: raising the pool size until the symptom moves, which usually just relocates the queue to the database.