Redis Interview Questions: Beyond Data Types and Into Consistency

Knowing the five common types is assumed. What earns credit is choosing one for a stated problem and defending it: a sorted set for a leaderboard because rank queries are logarithmic, a hash to avoid serialising a whole object for a one-field update.

Be ready to say when Redis was the wrong tool. Using it as a primary store without durability planning, or as a queue where a real broker was needed, are both real mistakes and naming one is more convincing than a flawless record.

Expect the order of operations question: update database then delete cache, or delete then update. Know that both have a race window and be able to describe it rather than asserting one is correct.

Know the standard mitigations and their costs: short expiry as a safety net, delayed double delete, or reading through a single path. Each trades staleness against complexity, and saying which you chose and why is the answer.

Know the three named failure modes and how they differ: penetration, where the key never exists; breakdown, where one hot key expires; avalanche, where many keys expire together. Different causes, different fixes, and mixing them up is a common and visible mistake.

Know what happens when memory is exhausted, that it depends on the eviction policy, and what the default does. Candidates who have run Redis near capacity know this and others usually do not.

Know why a single large key is a problem: it blocks, because the server is effectively single threaded for command execution. That fact explains several production incidents and interviewers use it to test depth.

Be able to say which commands are dangerous on a large production instance and what you use instead.

Know the two persistence mechanisms and what each loses in a crash. The precise answer is about the window of loss and the cost of the write path, not about which is better.

Know what a failover actually does to in-flight work and why a distributed lock built on a single instance is not safe across one. Have a view on whether that mattered for your use case.

The strongest answer here is an incident: what the symptom was, what you found, and what you changed. Redis failures are usually memory or blocking, and a specific story beats general knowledge.