Concept questionMedium~7 min

Interview question

What happens when Redis runs out of memory, and how would you design for it?

Handle Redis memory pressure and eviction policy

Explains Redis memory pressure, eviction policies, key sizing, TTL discipline, and what happens when the cache is full.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

When Redis reaches its memory limit, behavior depends on the configured policy. It may evict keys, reject writes, or evict only keys with TTLs. For cache-aside data, eviction usually means more cache misses and more source reads. For data treated like state, eviction can be a serious correctness problem.

Full answer below

Practice focus

Memory limits, eviction policy, TTL coverage, key/value size, cache misses, source load, and operational alerts.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A cache is allowed to forget things, but unplanned eviction can look like random latency, database spikes, or missing state.
When Redis reaches its memory limit, behavior depends on the configured policy. It may evict keys, reject writes, or evict only keys with TTLs. For cache-aside data, eviction usually means more cache misses and more source reads. For data treated like state, eviction can be a serious correctness problem.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would design cache entries with size and TTL in mind. Most cache data should have an expiration, and large values should be questioned because they consume memory and network bandwidth. The eviction policy needs to match the data: if Redis is a cache, evicting least-recently-used or TTL-bound keys may be acceptable. If Redis stores sessions or counters, memory pressure needs tighter capacity planning and alerts.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor memory usage, fragmentation, evicted keys, expired keys, rejected writes, key count, hit rate, and source load after evictions. I would avoid using one Redis database for unrelated workloads with different eviction tolerance, such as disposable product cache beside session state. If eviction rises, I would check which key patterns and payload sizes consume memory before changing capacity. The better fix may be key discipline, shorter TTLs, smaller values, splitting workloads, or capacity changes, not only raising the limit.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming Redis stores cached values forever.
Not knowing the eviction policy.
Mixing disposable cache and important state in the same eviction boundary.
Caching large values without measuring memory and bandwidth.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain what eviction does to the source system.
No memory metrics or alerts.
No TTL discipline.
Treats Redis as durable storage for values that can be evicted.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What Redis data can be evicted safely?
How would eviction show up in API metrics?
When would you split Redis workloads?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Unbounded Cache

Opening drill

Concept questionMedium~7 min

Interview question

What happens when Redis runs out of memory, and how would you design for it?

Handle Redis memory pressure and eviction policy

Explains Redis memory pressure, eviction policies, key sizing, TTL discipline, and what happens when the cache is full.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Memory limits, eviction policy, TTL coverage, key/value size, cache misses, source load, and operational alerts.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A cache is allowed to forget things, but unplanned eviction can look like random latency, database spikes, or missing state.
When Redis reaches its memory limit, behavior depends on the configured policy. It may evict keys, reject writes, or evict only keys with TTLs. For cache-aside data, eviction usually means more cache misses and more source reads. For data treated like state, eviction can be a serious correctness problem.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would design cache entries with size and TTL in mind. Most cache data should have an expiration, and large values should be questioned because they consume memory and network bandwidth. The eviction policy needs to match the data: if Redis is a cache, evicting least-recently-used or TTL-bound keys may be acceptable. If Redis stores sessions or counters, memory pressure needs tighter capacity planning and alerts.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor memory usage, fragmentation, evicted keys, expired keys, rejected writes, key count, hit rate, and source load after evictions. I would avoid using one Redis database for unrelated workloads with different eviction tolerance, such as disposable product cache beside session state. If eviction rises, I would check which key patterns and payload sizes consume memory before changing capacity. The better fix may be key discipline, shorter TTLs, smaller values, splitting workloads, or capacity changes, not only raising the limit.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming Redis stores cached values forever.
Not knowing the eviction policy.
Mixing disposable cache and important state in the same eviction boundary.
Caching large values without measuring memory and bandwidth.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain what eviction does to the source system.
No memory metrics or alerts.
No TTL discipline.
Treats Redis as durable storage for values that can be evicted.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What Redis data can be evicted safely?
How would eviction show up in API metrics?
When would you split Redis workloads?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Unbounded Cache

What happens when Redis runs out of memory, and how would you design for it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

What happens when Redis runs out of memory, and how would you design for it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper