Hello - I'm Masab Qurban, a Senior Software Engineer working on scalable SaaS with React.js, Next.js, Node.js, and PostgreSQL. One of the clearest wins I've shipped recently wasn't a new feature. It was making an existing API feel fast again.
We had endpoints averaging around ~850ms. After a focused pass on caching and schema design, the same paths landed under 180ms. Here's the approach that actually moved the needle.
Find the real bottleneck first
Before adding Redis, measure. Log query times, count round-trips, and check whether you're paying for N+1 Prisma includes, missing indexes, or repeated reads of the same tenant data on every request.
In our case, the hot path wasn't one huge query - it was several medium queries that ran on almost every authenticated request. Perfect candidates for a short-lived cache.
Cache the expensive, stable reads
Redis works best when you cache read-heavy, tenant-scoped payloads with clear invalidation rules:
- Key by tenant + resource (e.g.
tenant:123:dashboard:summary) - Use short TTLs for near-real-time data (30-120 seconds)
- Invalidate on writes - don't wait for TTL when a user updates a record
- Fail open: if Redis is down, hit Postgres and log the miss
That alone removed most of the repeated database work from the critical path.
Tighten the Prisma + PostgreSQL layer
Caching hides bad queries - it doesn't fix them. Pair Redis with schema work:
- Select only the fields you need (
selectover fatincludetrees) - Add indexes that match real
where+orderBypatterns - Avoid loading relation graphs when a denormalized summary will do
- Batch lookups instead of looping
findUniquecalls
After indexes and leaner queries, the cache miss path was still fast enough that users rarely felt a cold start.
What I'd do again
Instrument first. Cache the hottest tenant reads. Invalidate on write. Then fix Postgres so a cache miss still feels snappy. That combination - Redis + Prisma/PostgreSQL discipline - is what took us from ~850ms to under 180ms in production.
If you're building SaaS on Next.js and Node.js and hitting similar latency walls, start with measurement, not another library.
