Backend & Node.js · APIs, data and failure
What is Redis good for in a backend system?
Short answer
Redis is an in-memory data store used for caching, sessions, rate limiting, queues, distributed locks and leaderboards. Its atomic commands and rich data structures make it useful beyond simple key-value caching.
Redis keeps data in memory, so reads and writes are fast. It supports strings, hashes, lists, sets, sorted sets, streams and expirations. That makes it a shared building block for state that must be fast and accessible from many application instances.
await redis.set("session:" + id, JSON.stringify(data), { EX: 3600 });
await redis.zadd("leaderboard", score, userId);
await redis.incr("rate:" + ip);
const top = await redis.zrevrange("leaderboard", 0, 9);Good uses
- Cache-aside for expensive queries and rendered fragments
- Session storage shared across instances
- Rate limiting with atomic increments or Lua scripts
- Short-lived distributed locks with a fencing token or ownership check
- Leaderboards and rankings with sorted sets
- Lightweight job queues and streams when a full broker is overkill
Redis is not automatically durable. Persistence depends on configuration, and replication is asynchronous unless you use the appropriate guarantees. Treat it as a cache or fast shared state, not as the source of truth for critical records, unless you have designed and tested the durability model.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Is Redis durable enough to be a primary database?
- 2How do you implement a distributed lock with Redis?
- 3Why is KEYS dangerous in production?
- 4How does a sorted set support a leaderboard?
Say it in the interview
Redis is an in-memory store with fast atomic operations and useful data structures. I use it for caching, shared sessions, rate limiting, leaderboards and short-lived locks. I do not treat it as a durable source of truth unless persistence and replication are designed for that. I also avoid expensive operations such as KEYS on large keyspaces and use pipelining for throughput.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Backend & Node.js mock interview and get scored feedback on depth, clarity and confidence.