Fix the design · Incident triage

Order List N+1: The Page That Hits the Database 151 Times

An order dashboard endpoint feels slow in QA when about fifty orders are on screen because related data is loaded in a way that multiplies database work.

In a low-level design interview, the interviewer opens an order dashboard endpoint and asks what happens when about fifty orders are on the screen, and how you would make the page faster.

We need your help. Identify what is inefficient in how data is loaded, then fix the path from “open dashboard” → “rows on screen” so the same page uses far fewer database round trips as the order count grows.

Problem

Fix the team’s existing order dashboard endpoint — it already loads a shop’s orders and, for each order, the line items, customer name, and shipment status.

Incident summary

  • In QA, the dashboard feels slow when about fifty orders are on the screen.
  • Database activity spikes on each page load in the QA logs.
  • The team assumed the framework would fetch related data on its own without a clear plan.

Assumptions made by the team

  • The framework will load related rows automatically, so we do not need to plan the fetches ourselves.
  • Fifty orders is a small list, so a few extra database queries will not matter.
  • If the page becomes slow, we can fix it later with caching.
  • Keeping everything in one method is simpler and fine for now.
  • Adding a database index alone is enough to speed this up.

Impacted services

  • Controller (healthy) — The route is fine — the problem is how data is loaded below it.
  • Service / loop (critical) — Fetches items, customer, and shipment inside a loop over every order.
  • Data access layer (degraded) — Each findByOrderId or findById is a separate trip to the database.
  • Database (degraded) — Not broken — just asked the same kind of question hundreds of times per page.

Triage questions

  1. What performance issue do you notice in this implementation?
  2. Approximately how many database queries would run if 50 orders are returned?
  3. How would you optimize how items, customers, and shipments are loaded? Name one approach you would actually use.
  4. If we add reviews as a fourth related table, what happens to query count — and when is one fetch per row still okay?

← All design challenges

Loading scenario…