An endpoint runs one query for the list and then one query per row. How would you explain and fix that?

Diagnose the N plus one query pattern

Explains N plus one query behavior, symptoms in APIs, fixes with set-based reads, batching, projections, and monitoring.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

N plus one means the application runs one query to get parent rows and then runs another query for each parent row. With 100 parents, that can become 101 database calls. I would fix it by fetching related data in a set-based way: a join, projection, grouped query, explicit include, or second query using WHERE parent_id IN (...). The goal is to keep query count bounded.

Full answer below

Practice focus

N plus one detection, set-based loading, batching, projections, ORM behavior, and API performance.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
N plus one is one of the most common backend data-access failures. It is also easy to explain well when the candidate can connect logs, SQL, and API latency.
N plus one means the application runs one query to get parent rows and then runs another query for each parent row. With 100 parents, that can become 101 database calls. I would fix it by fetching related data in a set-based way: a join, projection, grouped query, explicit include, or second query using WHERE parent_id IN (...). The goal is to keep query count bounded.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would diagnose it from SQL logs, telemetry, or database command count per request. The best fix depends on the response shape. A join may duplicate parent rows, so a projection or split query can be cleaner. If only counts are needed, I would aggregate in SQL rather than load children. In EF Core, lazy loading can hide N plus one behavior, so I would prefer explicit query shapes for important endpoints.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Fixing N plus one by caching every child query.
Using Include blindly and returning huge object graphs.
Ignoring page size.
Not checking generated SQL or query count.

An endpoint runs one query for the list and then one query per row. How would you explain and fix that?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Suggest an improvement