Performance
N+1: multiple-choice review
Crux Multiple-choice synthesis across the N+1 unit — round-trip cost, fix-family choice by cardinality, DataLoader, off-CPU detection, pool exhaustion, and DoS amplification.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make in a real incident — not a definition to recite, but a fix to pick when the query log is in front of you and the page is slow.
Goal
Confirm you can connect the round-trip cost model, the four fix families, the detection instruments, and the second-order failures — the synthesis the individual lessons built toward.
Quiz
Completed
A list page fires 51 queries at 0.4 ms each but the wall-clock is 765 ms. The DBA insists every query is fast and the indexes are fine. How do you reconcile this?
Heads-up The queries genuinely are fast server-side. The 765 ms is round-trip latency × 51, not slow execution. Speeding up each query does almost nothing here.
Heads-up An index lowers per-query execution time, already at 0.4 ms. The bottleneck is the 51 round-trips' latency, which an index does not touch. You need fewer trips, not faster ones.
Heads-up The time is spent off-CPU waiting on the database socket between trips, not burning CPU. A CPU profile would look flat — the classic N+1 signature.
Quiz
Completed
A page loads 50 orders, each with ~20 line items. You fix the N+1 with a JOIN and query count drops 51 → 2, but p99 gets 30% worse. What happened and what is the fix?
Heads-up Eager loading almost always wins by collapsing round-trips. The regression here is the JOIN strategy for heavy one-to-many fan-out, not eager loading itself.
Heads-up This is a JOIN, not an IN query — there is no IN list. The cost is row duplication from the JOIN, which IN-based loading would avoid.
Heads-up Two queries beat 51 round-trips on latency; the regression is payload bloat from JOIN duplication. The fix is IN-based loading, not reverting to N+1.
Quiz
Completed
A GraphQL query me { posts { author { name } } } over 50 posts fires 1 + 50 author lookups. Why can't ORM eager loading (.includes / select_related) fix this, and what can?
Heads-up Each resolver runs independently per parent object with no shared query site. There is nowhere to attach .includes that batches across the 50 separate author resolvers — that is exactly why DataLoader exists.
Heads-up GraphQL has no opinion on SQL. The blocker is the scattered, per-resolver nature of the lookups, not any prohibition on JOINs.
Heads-up That is a workaround that shrinks the symptom; the structural 1+N pattern remains. DataLoader removes the pattern regardless of fan-out size.
Quiz
Completed
A REST aggregator calls 8 downstream services serially at 30 ms each (240 ms p99). A SQL N+1 on a list page also costs ~240 ms. Are these the same problem, and do they share a fix?
Heads-up Both are the same N-round-trips shape one protocol level apart. The unit's whole point is that N+1 is protocol-agnostic; only the batching mechanism differs.
Heads-up Parallel SQL still pays N round-trips and can saturate the connection pool. SQL to the same DB should be batched into one query, not fanned out in parallel.
Heads-up Protocol speed gives an incremental win. The structural fix is collapsing trips: batch the SQL, parallelise the independent service calls.
Quiz
Completed
A service with a 25-connection pool starts returning 503s under load. Individual query latency is stable, the DB is healthy, but pool saturation is pinned near 100% and the request queue is growing. Root cause and first fix?
Heads-up Enlarging the pool defers the wall but shifts contention onto the database and masks the cause. The real lever is shorter connection hold-time, achieved by killing the N+1.
Heads-up A leak makes active count climb and never recover. Here connections are released — just slowly, because each request runs ~50 serial queries before releasing.
Heads-up Individual query latency is stable, so the DB is not the bottleneck. The application is holding connections too long across serial queries.
Quiz
Completed
A public GraphQL endpoint lets clients control nesting depth and page size. A single crafted request spikes the DB to thousands of queries. How should a senior frame this, and what is the durable guard?
Heads-up Fixing one path helps, but on a public endpoint with user-controlled fan-out the issue is a security/availability vector. It needs depth/complexity bounds, not only a one-path fix.
Heads-up Rate limiting blunts volume but one expensive request can still amplify thousands of queries. You must bound per-request cost via depth and complexity limits.
Heads-up Replicas raise capacity but the attacker scales fan-out with the request; you'd be paying to serve an attack. Bound the per-request query cost instead.
Recap
The through-line of the unit is one decision tree: count the round-trips first (the cost is trip count, not per-query speed), then pick the fix by cardinality — JOIN for one-to-one, IN/selectinload for heavy one-to-many, preload when the shape is known at the query site, DataLoader when lookups are scattered across resolvers, and parallel dispatch when independent services share no backend. Detect it off-CPU via query logs and APM waterfalls, gate it in CI, and remember the second-order failures: JOIN payload bloat, connection-pool exhaustion, query-plan flips, and DoS amplification.