A service loads 100 orders, then for each order calls a lazily-loaded getLineItems() to compute a total. The endpoint that used to take 50ms now takes 4 seconds under real data. Walk through why lazy loading causes this, and how you'd fix it.

## Tracing the queries The N+1 query problem is the single most common production symptom of lazy loading, and it's worth tracing exactly why it happens rather than just naming it. 1. Start with the query that loads the 100 orders — that's one round trip to the data store, query #1. 2. Each returned `Order` object, though, has its line items represented by a lazy placeholder rather than actual data (per whichever Lazy Load variant is in use — a virtual proxy or a lazily-initialized collection are the common cases in ORMs). 3. The code then loops over the 100 orders and calls `getLineItems()` on each one to sum a total. 4. Because each order's line items were never fetched by the original query, that first access on **each** order independently triggers its own load — a fresh round trip to fetch just that order's items. 5. Loop iteration 1 fires query #2, iteration 2 fires query #3, and so on, up through iteration 100 firing query #101. Hence **N+1**: the 1 initial query for the parents, plus N further queries, one per parent, for their children — 101 total queries where a well-written access pattern needs only 1 or 2. ## Why it scales into a cliff Why does this hurt so much in production but not in a small test dataset? Because the damage scales **linearly with N**, and each of those N extra queries pays a mostly-fixed per-round-trip cost that dwarfs the actual work of fetching a handful of line-item rows: - connection/thread handoff; - network latency; - driver overhead; - database query-planning overhead. With N=5 in a unit test, the extra overhead is a few milliseconds and invisible. With N=100 orders in production, each round trip costing even 30-40ms of network+parsing overhead, you get exactly the jump from 50ms to 4 seconds described in the scenario. ## Why nothing in the code looks wrong The failure is also structurally invisible in code review: the loop body just calls a getter that **looks** like a cheap in-memory field access, so nothing about the code's shape signals 'this issues a database query.' It typically first shows up not in development, where test fixtures are small, but under real traffic and real data volume, often flagged by: - a slow-query monitor; - an APM trace showing a suspicious burst of near-identical queries; - a user complaint about a slow page — well after the code has shipped. ## Three ways to fix it Fixing it means replacing the per-parent lazy trigger with a single bulk fetch for the whole batch, and there are a few standard techniques. 1. The most direct is an **eager fetch join** scoped to this one query — in JPQL/HQL terms, something like `SELECT o FROM Order o JOIN FETCH o.lineItems WHERE ...`, which tells the ORM to pull line items in the **same** query as the orders via a SQL join, producing 1 query total instead of 101. This is deliberately scoped to the one use case that needs it, rather than making the association eager everywhere — a global eager-fetch default just moves the 'load everything unconditionally' cost to every code path, including the ones that never touch line items at all. 2. A second technique is a **manual batched fetch**: after loading the 100 orders, issue one additional query with `WHERE order_id IN (...)` across all 100 order ids at once, fetch all their line items in that single query, and stitch them onto the in-memory `Order` objects yourself, or let the ORM's batching feature do this automatically (Hibernate's `@BatchSize` annotation, for example, groups deferred single-entity loads into chunks of, say, 20 at a time, turning 101 queries into roughly 6). 3. A third, often cleanest, technique for read-heavy endpoints is to bypass the lazy-loaded domain graph entirely for this access path and write a purpose-built **projection or DTO query** that selects exactly the columns needed (order id, and a pre-aggregated sum of line item totals via a JOIN and GROUP BY) in one round trip, which sidesteps the N+1 risk altogether because there's no lazy field being touched in a loop in the first place. ## The deeper lesson The deeper lesson is that lazy loading's default behavior is fine for single-object, single-field access (load one `Customer`, read one lazy field, done — one extra query is nothing) but actively dangerous inside any loop over a collection of parents, because the **same** single-object cost that was negligible once becomes N times the cost when repeated, and lazy loading, by design, gives you no visibility at the call site that you're inside such a loop.