Caching, N+1 & Performance¶

Once CRUD works, make it fast. Two issues dominate: the N+1 query problem and missing caches.

The N+1 Query Problem¶

1const tasks = await prisma.task.findMany();      // 1 query
2for (const t of tasks) {
3  t.owner = await prisma.user.findUnique({ where: { id: t.ownerId } }); // N queries!
4}

Twenty tasks → twenty-one queries. This is the N+1 problem, the #1 cause of slow list endpoints.

The Fix: Fetch Relations in One Go¶

1const tasks = await prisma.task.findMany({
2  include: { owner: { select: { id: true, name: true } } },
3});

One query (or a small constant number). Always load the relations you'll render up front.

Caching Reads¶

Reads usually outnumber writes 100:1. Cache them.

1const cached = await redis.get(key);
2if (cached) return JSON.parse(cached);
3const data = await prisma.task.findMany({ where });
4await redis.set(key, JSON.stringify(data), "EX", 60); // 60s TTL
5return data;

Invalidate on Write¶

A cache is only safe if writes clear it. After any Create/Update/Delete, bust the relevant keys:

1await prisma.task.update({ where: { id }, data });
2await redis.del(`tasks:${ownerId}`);  // the read cache is now stale — drop it

"There are only two hard things in computer science: cache invalidation and naming things." Cache the obvious wins, invalidate on every write, and measure before optimizing further.

Measure First¶

Add query logging and timing. Optimize the endpoints that are actually slow under real traffic — not the ones you guess are slow.