Solving the N+1 query problem in Sequelize

WHAT THIS TESTS The interviewer wants to know if you understand how ORMs translate object access into SQL, and whether you can spot a hidden performance trap that scales linearly with row count.

A GOOD ANSWER COVERS The N+1 problem occurs when you run one query to fetch a list (the 1), then a separate query for each row to load its association (the N). For 100 blogs that is 101 queries instead of 1. In Sequelize this happens with lazy loading: you call Blog.findAll, then access blog.getAuthor or query Author by foreign key inside a loop. The fix is eager loading, passing include into the query so Sequelize builds a single statement with a JOIN: Blog.findAll with include set to the Author model. You can also use separate true on a hasMany include to issue one extra batched query instead of one per row, which avoids row duplication on large joins.

COMMON WRONG ANSWERS Claiming the ORM automatically batches everything, confusing N+1 with slow queries generally, or proposing to add database indexes as the primary fix. Indexes help each query but do not reduce the count.

LIKELY FOLLOW-UPS How do you detect it (enable logging in the Sequelize constructor, or use an APM that flags repeated queries), when is separate loading better than a JOIN (large hasMany sets where the JOIN multiplies parent rows), and how does pagination interact with includes.

ONE CONCRETE EXAMPLE Bad: const blogs = await Blog.findAll(); for the blogs, await Author.findByPk(blog.authorId) inside a loop produces 1 plus N queries. Good: const blogs = await Blog.findAll with include set to Author, which emits a single SELECT joining blogs and authors and populates blog.Author on each instance.