@capacitadev: The N+1 Problem — and How to Kill It You write a loop. It looks clean. The tests pass. Then production slows to a crawl under real data. The culprit? N+1. Here's what's happening: your app loads a list of 100 orders. Then, for each order, it fires a separate query to get the customer. That's 1 + 100 = 101 queries. With 500 orders it's 501. Under 10 concurrent users, that's 5,010 database round-trips for one page load. Each query carries overhead: network latency, connection acquisition, query parsing, and execution plan lookup. Individually they're fast. Multiplied across N records under real load, they drain your connection pool and tank your response times. The fix is straightforward once you see it. In Entity Framework Core, Include() tells the ORM to JOIN the related table in a single query instead of querying lazily per record. If you only need specific fields, Select() into a DTO is even better — it avoids loading full entity graphs and produces a leaner SQL query. The key rule: never access a navigation property inside a loop without explicitly loading it first. To detect it: enable EF Core SQL logging in development. If you see the same query repeating with different IDs, you have an N+1. Tools like MiniProfiler make this visible at a glance. In interviews, when you hear "it slows down as data grows," think N+1 first. Follow @capacitadev on Instagram and TikTok for interview prep content across Junior, Intermediate, Senior, and Staff levels. There's a free PDF with 20 interview questions waiting for you in the link on the profile. #dotnet #csharp #entityframework #efcore #softwareengineering

CapacitaDEV

Open In TikTok:

Region: CL

Tuesday 09 June 2026 23:09:57 GMT