[!NOTE] Redis questions test whether you can reduce database load without creating stale-data, consistency, or availability problems.
🧭 At a Glance
| Area | Interview Answer |
|---|---|
| Use case | Cache read-heavy data, sessions, rate-limit counters, leaderboards, and short-lived computed results. |
| Default pattern | Use cache-aside: read Redis first, fallback to DB on miss, then populate Redis with TTL. |
| Big risk | Stale data, cache stampede, hot keys, and treating Redis as the source of truth. |
| Production signal | Talk about TTLs, invalidation, monitoring, fallbacks, and what happens when Redis is down. |
📌 Real Interview Prompt
Question: How would you use Redis cache in a backend service to improve performance?
✅ Short Answer
I would use Redis as a fast in-memory cache in front of the database. For read-heavy data, the service first checks Redis. If the key is present, it returns the cached value. If not, it reads from the database, stores the result in Redis with a TTL, and returns the response. I would also define invalidation rules for updates, protect against cache stampede, monitor hit ratio, and keep the database as the source of truth.
🛠️ Cache-Aside Flow
Client -> API -> Redis
| hit -> return cached response
| miss -> Database -> Redis SET with TTL -> return response
🔍 What Interviewers Evaluate
- Do you know when Redis helps and when it adds complexity?
- Can you explain cache invalidation instead of only saying "add Redis"?
- Can you protect the database during cache misses?
- Can the service survive Redis downtime?
💬 Expandable Q/A
What data should be cached?
Cache data that is read frequently, expensive to compute, and acceptable to serve slightly stale. Examples include product details, user profiles, configuration, access permissions, and aggregated dashboards.
How do you handle updates?
Use explicit invalidation for critical data: update the database, then delete or refresh the Redis key. TTL acts as a backup safety net, not the only correctness mechanism.
What is cache stampede?
Cache stampede happens when a popular key expires and many requests hit the database together. Use TTL jitter, request coalescing, locks, stale-while-revalidate, or background refresh.
What if Redis goes down?
The service should degrade gracefully by reading from the database, using timeouts, limiting traffic, and alerting. Redis should not be required for core correctness unless the product explicitly accepts that trade-off.
⚠️ Common Mistakes
- Using Redis as the primary database without discussing durability.
- Not setting TTLs.
- Invalidating only some keys after writes.
- Ignoring hot keys and cache stampede.
- Not monitoring hit ratio, latency, evictions, and memory usage.
📝 Final Summary
A strong Redis answer is not just "put Redis before DB." Say what you cache, how you expire it, how writes invalidate it, how you handle misses, and how the system behaves when Redis is unhealthy.