Diagnosing and fixing the N+1 query problem

WHAT THIS TESTS The interviewer checks whether you understand how convenient ORM abstractions generate pathological query volume, and whether you can fix it structurally rather than masking it.

A GOOD ANSWER COVERS The N+1 problem occurs when code runs one query to fetch N parent records, then issues a separate query for each parent to load its related children, totaling N+1 round trips. The dominant cost is usually per-query latency and network overhead, not raw row count. The query-level fix is to fetch everything in one statement using a JOIN, or to collect parent IDs and issue a single batched query with a WHERE id IN (...) clause, then stitch results in memory. At the ORM level you switch from lazy to eager loading: use joined or subquery loading, or an explicit prefetch step so the framework batches the child fetch into one or two queries.

COMMON WRONG ANSWERS Throwing caching at it without reducing query count, which only hides the issue and adds invalidation complexity. Increasing the connection pool or database size, treating a round-trip problem as a capacity problem. Blindly using a JOIN that fans out rows and inflates payload when a batched IN query would be leaner.

LIKELY FOLLOW-UPS When is a JOIN worse than a batched second query due to row multiplication? How do you detect N+1 in production using query logs or APM traces? How does cursor-based pagination interact with eager loading?

ONE CONCRETE EXAMPLE A blog page lists 50 posts and shows each author's name. Lazy loading runs one query for posts, then 50 queries for authors, 51 total. Eager loading with a join or a single WHERE author_id IN (the 50 ids) collapses this to two queries, cutting latency dramatically under load.