Your /orders endpoint loads 50 orders on a page.
P95 is 2.4s. The DB’s fine. The app server’s fine. Nothing’s on fire.
Then you open the query log.
51 queries per request. One SELECT for the orders list. Then 50 more — one per order — to fetch the customer. The ORM is doing lazy-load on order.customer inside your map.
Classic N+1. You’ve seen it before. The fix is “obvious” — until the team meeting, where three engineers propose three different things and everyone thinks they’re right.
Here’s what’s on the table:
A) Eager-load the relation — include: { customer: true } on the Prisma query. One JOIN, done.
B) Add a DataLoader in front of the customer lookup — batches the 50 IDs into one WHERE id IN (…) behind the scenes.
C) Cache the customer by ID in Redis — every lookup hits cache first, DB only on miss.
D) Denormalize customer_name onto the orders table — read it straight from the orders row, no join, no second query.
All four get the query count down. All four ship to prod in real codebases. But the pattern you pick is a bet on what this endpoint becomes in 6 months, not what it is today.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments, including which two answers senior engineers split on in code review (and which one is a career-long argument I still watch play out).
If your team has had this exact fight in Slack, send them this post. The debate is worth more than the post.
Drop your answer 👇
#30DaysOfSystemDesign #SystemDesign #Backend #Databases

Joud Awad

A classic N+1 query problem is presented: a /orders endpoint fires 51 DB queries per request due to ORM lazy-loading customer data. Four solutions are compared — eager loading with a JOIN (Prisma include), DataLoader batching, Redis caching, and denormalization — each with different trade-offs for future scalability. The post frames it as a team debate exercise rather than providing a definitive answer.

2/30 Days System Design Questions!

Why A wins: One LEFT JOIN customers ON orders.customer_id = <a href="http://customers.id" target="_blank" rel="noopener nofollow">customers.id</a> returns the whole page in a single round trip. P95 drops from 2.4s to ~80ms. No new infrastructure. No new failure modes. The N+1 problem in an ORM almost always has the same root cause: a lazy relation the developer didn’t realize was lazy. Prisma’s include, Sequelize’s include, TypeORM’s relations — every ORM has this. Reach for fancier patterns only when JOIN genuinely can’t solve it.
<img src="https://media.daily.dev/image/upload/s--tl9l5a07--/f_auto/v1778181953/ugc/content_c0fa47b7-0c04-4a60-b493-c18e24870585?_a=BAMAMiWQ0" alt="ChatGPT Image May 7, 2026, 10_22_24 PM (1).png">

Why B is the trap (DataLoader): Beautiful pattern — but earns its keep in GraphQL where the resolver graph fans out in ways a single JOIN can’t express. Here you have one list endpoint with one relation. A JOIN is strictly simpler and strictly faster. You’re solving a problem you don’t have and paying the complexity tax forever.

Why D is the career-long argument (denormalize): Legitimate at Instagram scale. Also how you end up with a customer’s maiden name three years after they got married because nobody wrote the update path. Denormalization is a write-amplification decision masquerading as a read-optimization. Do it when the JOIN genuinely can’t hit your latency SLO at your scale — not before.

Why C is wrong (Redis): Cache-first fixes the symptom, not the query pattern. You still issue 50 cache GETs per request, now own a cache invalidation problem every time a customer updates, and cold-hit every ID after a deploy. Cache is a scaling tool, not an N+1 tool.

Could do A and C? But my gut feeling is it’s always going to be a miss in cache and adding redis just for that would be over engineering. So begs the question:when to add redis and when not.