Learn the vocabulary of one query turning into N extra queries inside a loop, and how batching fixes it.
0 / 5 completed
1 / 5
At standup, a dev mentions an ORM lazy-loading each order's line items one query at a time inside a loop, so listing 100 orders fires 101 separate queries instead of one. What is this pattern called?
The N+1 query problem is exactly this: one query to fetch the N orders, then one additional query per order to lazy-load its line items, for a total of N+1 round trips instead of a single join or batch fetch. Connection pooling only concerns reusing existing connections and says nothing about how many queries a page load issues. This pattern is one of the most common performance bugs introduced by an ORM's convenient lazy-loading default.
2 / 5
During a design review, the team wants all 100 orders and their line items fetched in a single query using a join or an explicit batch loader, instead of one query per order. Which capability supports this?
Eager loading, or a batching data loader, fetches all the related rows for every order in one round trip, typically via a join or a single WHERE IN query, instead of issuing a separate query per order. Continuing to lazy-load each order's line items individually is precisely the N+1 pattern the team is trying to eliminate. This batched fetching is what turns a linearly growing number of queries into a constant, small number regardless of how many orders are on the page.
3 / 5
In a code review, a dev notices a query-logging middleware reporting several hundred queries fired for a single page load that only displays 50 rows. What does this represent?
A likely N+1 query problem is exactly what several hundred queries for only 50 displayed rows suggests, since a well-batched page load should issue roughly a constant, small number of queries regardless of how many rows it renders. A cache hit ratio measures something else entirely and wouldn't explain a raw query count this high. This kind of query-count logging is a standard way to surface an N+1 bug that isn't obvious just from reading the code.
4 / 5
An incident report shows a product listing page started timing out once the catalog grew past a few thousand items, because each item's price lookup fired its own individual query inside a loop instead of one batched query. What practice would prevent this?
Batching the price lookups into a single query, such as a WHERE IN clause or a join, keeps the page issuing roughly the same number of queries regardless of how many items the catalog holds. Continuing to fire one query per item inside the loop is exactly what caused the timeout as the catalog grew past a few thousand items in this incident. This batching is the standard fix once an N+1 pattern has been identified as the source of a scaling problem.
5 / 5
During a PR review, a teammate asks why the team adds an explicit eager-load hint to a query instead of trusting the ORM's default lazy-loading behavior to fetch related data as it's needed. What is the reasoning?
Lazy loading fetches related data one row at a time as it's accessed, which turns into exactly one query per row once that access happens inside a loop over many parent rows. An explicit eager-load hint fetches all the related data in one batched query upfront, before the loop even starts, avoiding that per-row cost entirely. The tradeoff is that eager loading can over-fetch related data the loop never actually ends up needing, so it's best applied deliberately where the N+1 pattern is a known risk.