6
System Design
Redis cache vs just querying the database — when is caching worth it?
Latency ↔ Consistency
Context
Product pages are slow (p95 400ms). Add a cache or fix queries?
Our product detail endpoint does 14 queries and takes ~400ms at p95. A teammate wants to put Redis in front of it. I suspect we should fix the queries first, because cache invalidation will bite us when prices change.
How do you decide whether a slow endpoint needs a cache or just better queries?
Constraints
- Read/write
- 50:1
- p95 target
- < 100ms
Add RedisvsOptimise the database
Community verdict
Add Redis 38%Optimise the database 62%
8 engineers · 3 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Add Redis
Optimise the database
Consistency →
Trade-offs
Dimensions
Add RedisOptimise the databaseout of 5
- Latency
- 5Add Redis scores 5 of 53Optimise the database scores 3 of 5
- Consistency
- 2Add Redis scores 2 of 55Optimise the database scores 5 of 5
- Complexity
- 2Add Redis scores 2 of 5
Community discussion
3 comments
Have you made this decision in production? Share your reasoning.
Sign in to comment14 queries is an N+1 smell. Fix that first — batch with a join or an IN query and add the missing index. Then measure. Caching a slow query just hides the problem until the cache misses.
Ran EXPLAIN ANALYZE as you suggested — two sequential scans. Adding two indexes took p95 from 400ms to 70ms. No cache needed for now.
At a 50:1 read/write ratio, a short-TTL cache (30–60s) on rendered product data is low risk and absorbs traffic spikes. Prices can bypass the cache or invalidate explicitly.