Redis

What problem does Redis solve?#

Your application repeatedly serves small objects, increments shared counters, ranks scores, or coordinates temporary state across many servers. Reading the durable database for every operation wastes capacity. Redis places typed, memory-oriented shared state on a shorter path - but the interview is about what happens when that state is stale, full, partitioned, or unavailable.

Mental model and core architecture#

Shared low-latency state with an explicit durable boundary

Application servers use a Redis cluster for shared fast state and a durable database where the workload requires an authoritative source. A Redis primary shard replicates to replicas.

Redis can sit in front of a database as a cache or serve counters, sessions, ranking, rate-limit state, coordination, and some stream/queue workloads. Those uses do not share one durability requirement.

Choose a structure from the access pattern#

Structure	Interview use	Question to ask
String	Cached object, session, counter	Is the value bounded and independently replaceable?
Hash	Fields for one logical object	Do fields change independently?
List	Simple ordered ends or queue-like work	Do I actually need acknowledgement or replay semantics?
Set	Membership and set operations	Is exact membership required?
Sorted set	Leaderboard and score ordering	What scope and time window define rank?
Stream	Retained append-oriented events	Would a dedicated streaming platform better fit retention and operations?

TTL, expiration, and eviction are separate decisions#

user:42 → TTL 300 seconds can bound a cache, session, rate-limit window, or temporary record. Expiration is not a promise that every key disappears at the exact wall-clock instant. Cross-link TTL; then separately decide what Redis should do at its configured memory limit.

Policy family	Meaning
LRU-oriented	Prefer removing less recently used candidates.
LFU-oriented	Prefer removing less frequently used candidates.
TTL-oriented	Prefer keys with expiration characteristics.
No eviction	Reject memory-growing writes instead of silently choosing victims.

The exact Redis policy must match whether losing a value means a harmless miss, a degraded feature, or broken correctness. Review the canonical eviction lesson first.

Persistence and replication do not create one universal durability guarantee#

Redis can use point-in-time RDB snapshots, append-only AOF logging, both, or no persistence. Recovery point and latency depend on configuration. Replication is normally asynchronous, so an acknowledged primary write may not yet exist on a replica when failure occurs. Persistence and replicas improve recovery options; neither automatically makes Redis the correct primary store for every workload.

Failure deep dive

Failure: The Redis tier is unavailable or has just failed over.
Impact: Cache misses or transient-state reads surge toward downstream systems; some recent state may be absent depending on replication and persistence choices.
Detection: Track errors, latency, memory pressure, evictions, replication health, and downstream load.
Mitigation: Use bounded timeouts, request coalescing, admission control, gradual warming, replicas where appropriate, and a deliberate degraded mode.
Trade-off: Falling back to the database preserves features only while that database can absorb the traffic.

Cluster scaling partitions keys, not request popularity#

Redis Cluster assigns keys to a fixed set of hash slots that nodes own; it is not generic consistent hashing. Moving slots changes ownership as the cluster changes. A cluster expands aggregate memory and throughput, but a celebrity key at 200,000 RPS still concentrates on its owner even when ordinary keys average 100 RPS.

Worked example

A hot key survives even distribution

ordinary key   = 100 RPS
celebrity key  = 200,000 RPS

Even key counts across shards ≠ even request load.

Consider application-local caching, read distribution where the topology supports it, explicit replicated copies, or request coalescing. Validate correctness and invalidation for every copy.

When to choose it - and when not to#

Choose Redis when	Do not add Redis merely when
A shared cache removes meaningful repeated work.	The primary database already meets latency and load requirements.
Atomic counters, TTL state, membership, or ranking fit native structures.	You need arbitrary relational queries or unbounded large values.
The failure and durability contract is explicit.	“Memory is fast” is the only justification.

Compared with Memcached, Redis offers richer structures plus persistence, replication, and broader coordination options; Memcached offers a simpler distributed-memory-cache model. Choose from workload and operational needs, not unsupported benchmark folklore.

Common mistakes

Calling Redis only a cache - or automatically a database replacement.
Claiming it never persists or always persists safely.
Assuming Cluster solves hot keys.
Assuming database fallback can absorb a total cache outage.
Treating a simple lock acquisition as correct under every pause, partition, and lease-expiry case.
Ignoring key/value size and finite memory.

Interviewer follow-ups

Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.

What happens when Redis is unavailable?
What receives a TTL, and how was that duration chosen?
How do you scale beyond one node and handle a hot key?
Would Redis own the primary user record?
How is the database protected during recovery?

Apply the lesson

What problem does Redis solve?#

Mental model and core architecture#

Shared low-latency state with an explicit durable boundary

Application servers use a Redis cluster for shared fast state and a durable database where the workload requires an authoritative source. A Redis primary shard replicates to replicas.

Choose a structure from the access pattern#

Structure	Interview use	Question to ask
String	Cached object, session, counter	Is the value bounded and independently replaceable?
Hash	Fields for one logical object	Do fields change independently?
List	Simple ordered ends or queue-like work	Do I actually need acknowledgement or replay semantics?
Set	Membership and set operations	Is exact membership required?
Sorted set	Leaderboard and score ordering	What scope and time window define rank?
Stream	Retained append-oriented events	Would a dedicated streaming platform better fit retention and operations?

TTL, expiration, and eviction are separate decisions#

Policy family	Meaning
LRU-oriented	Prefer removing less recently used candidates.
LFU-oriented	Prefer removing less frequently used candidates.
TTL-oriented	Prefer keys with expiration characteristics.
No eviction	Reject memory-growing writes instead of silently choosing victims.

The exact Redis policy must match whether losing a value means a harmless miss, a degraded feature, or broken correctness. Review the canonical eviction lesson first.

Persistence and replication do not create one universal durability guarantee#

Failure deep dive

Failure: The Redis tier is unavailable or has just failed over.
Impact: Cache misses or transient-state reads surge toward downstream systems; some recent state may be absent depending on replication and persistence choices.
Detection: Track errors, latency, memory pressure, evictions, replication health, and downstream load.
Mitigation: Use bounded timeouts, request coalescing, admission control, gradual warming, replicas where appropriate, and a deliberate degraded mode.
Trade-off: Falling back to the database preserves features only while that database can absorb the traffic.

Cluster scaling partitions keys, not request popularity#

Worked example

A hot key survives even distribution

ordinary key   = 100 RPS
celebrity key  = 200,000 RPS

Even key counts across shards ≠ even request load.

Consider application-local caching, read distribution where the topology supports it, explicit replicated copies, or request coalescing. Validate correctness and invalidation for every copy.

When to choose it - and when not to#

Choose Redis when	Do not add Redis merely when
A shared cache removes meaningful repeated work.	The primary database already meets latency and load requirements.
Atomic counters, TTL state, membership, or ranking fit native structures.	You need arbitrary relational queries or unbounded large values.
The failure and durability contract is explicit.	“Memory is fast” is the only justification.

Common mistakes

Calling Redis only a cache - or automatically a database replacement.
Claiming it never persists or always persists safely.
Assuming Cluster solves hot keys.
Assuming database fallback can absorb a total cache outage.
Treating a simple lock acquisition as correct under every pause, partition, and lease-expiry case.
Ignoring key/value size and finite memory.

Interviewer follow-ups

Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.

What happens when Redis is unavailable?
What receives a TTL, and how was that duration chosen?
How do you scale beyond one node and handle a hot key?
Would Redis own the primary user record?
How is the database protected during recovery?

Apply the lesson

What you will learn

What problem does Redis solve?#

Mental model and core architecture#

Choose a structure from the access pattern#

TTL, expiration, and eviction are separate decisions#

Persistence and replication do not create one universal durability guarantee#

Cluster scaling partitions keys, not request popularity#

A hot key survives even distribution

When to choose it - and when not to#

Related practice problems

Finish this lesson

Redis

What you will learn

What problem does Redis solve?#

Mental model and core architecture#

Choose a structure from the access pattern#

TTL, expiration, and eviction are separate decisions#

Persistence and replication do not create one universal durability guarantee#

Cluster scaling partitions keys, not request popularity#

A hot key survives even distribution

When to choose it - and when not to#

Related practice problems

Finish this lesson