Redis interview questions: cache consistency, memory and recovery
Start with the failure and consistency contract. Then choose Redis structures, expiry and eviction policies, atomic operations, persistence and coordination rules that fit it, with explicit recovery and idempotency behavior.
Backend and platform roles using Redis directly or beside a durable datastore. · Practice guide, not an employer rubric. Redis examples are illustrative and were not run against a server. Behavior depends on the deployed Redis version, configuration and client.
Which Redis data type fits the operation?
Choose the structure whose native operations match the access pattern and keep work bounded. Strings, hashes, sets, sorted sets, lists and streams offer different update and iteration semantics.
A hash can update one field without reading and rewriting a full serialized document. A sorted set can maintain ordered scores, while a stream retains ordered entries for consumer processing. The fit depends on cardinality and update/query needs, not the type name alone.
State key ownership, expiry, expected size and maximum collection cardinality. A command that traverses a huge key can monopolize server work; relational joins or referential constraints point toward a different authoritative model.
Illustrative Redis command or pseudocode; no Redis server was used.
Illustrative, not executed.
Follow-up: What would make a relational store a better fit?
Joins, referential constraints, durable history and queries across records often favor a relational model. Match Redis type and operations to bounded access patterns.
TTL bounds entry lifetime but does not synchronize a cache with database commits. Define invalidation order and acceptable staleness explicitly.
A delayed cache fill can read an old database value, pause while another request commits and deletes the key, then write the old value back. Versioned values, an outbox, or a different update protocol can address the race when it matters.
Plan for Redis loss: the durable store remains authoritative, and cache misses should not overwhelm it. Coalesce only when duplicate fills create observed origin pressure.
Python-like pseudocode · Worked example
value = redis.get(key)
if value is None:
value = database.load(key)
redis.set(key, value, ex=60)
Illustrative Redis command or pseudocode; no Redis server was used.
Illustrative, not executed.
Follow-up: How can cache-aside still serve stale data?
A delayed loader can publish an old database value after another request commits and invalidates. Use versioning or a coordinated update if the race violates the freshness contract.
Expiry removes keys after their TTL; eviction selects keys under memory pressure according to the configured server-wide policy. With noeviction, memory-requiring writes fail.
A cache-only instance may use an allkeys policy; volatile policies consider only keys with TTL. Mixed authoritative and disposable keys need careful separation because the policy is not per key prefix.
Account for encoding and allocator overhead, replication and persistence headroom. Monitor rejected writes and memory growth; logical value length is not resident memory usage.
Redis configuration · Worked example
maxmemory 2gb
maxmemory-policy allkeys-lru
Illustrative Redis command or pseudocode; no Redis server was used.
Illustrative, not executed.
Follow-up: What is the difference between TTL expiry and eviction?
Expiry removes keys whose time has elapsed. Eviction chooses keys under memory pressure according to the server-wide maxmemory policy; neither is a per-key durability guarantee.
MULTI/EXEC queues commands and executes them without interleaving from other clients, but it is not SQL rollback. Runtime errors do not undo other successful commands.
WATCH enables optimistic conflict checks; the caller must retry if a watched key changes. A short script or function can perform a bounded read-check-write sequence atomically, but long scripts block other server work.
Validate inputs and invariants before mutation. Atomic execution does not mean durable storage, a transaction with PostgreSQL, or recovery from arbitrary application errors.
Redis CLI sketch · Worked example
WATCH inventory:sku-7
MULTI
DECR inventory:sku-7
EXEC # null result means a watched key changed
Illustrative Redis command or pseudocode; no Redis server was used.
Illustrative, not executed.
Follow-up: Does MULTI/EXEC roll back runtime command errors?
No. Redis executes queued commands without interleaving but does not undo successful commands when another command fails. Validate before mutation and handle WATCH conflicts with bounded retries.
RDB snapshots and AOF command logging have different recovery-point, write and restore costs. Choose against explicit loss and recovery objectives, then test restore.
RDB stores point-in-time snapshots. AOF records writes with a configured fsync policy. Redis can use both. Actual recovery behavior depends on configuration, disk, dataset and version; enabling persistence does not establish a tested backup.
Replication helps availability but does not protect against every accidental deletion or corruption. Exercise a restore and record measured recovery point and time in an isolated environment.
Operations checklist · Worked example
# Architecture review should state concrete targets:
acceptable_data_loss = 'defined by product'
recovery_time = 'defined by product'
# Then rehearse restore under the deployed persistence configuration.
Illustrative Redis command or pseudocode; no Redis server was used.
Illustrative, not executed.
Follow-up: What does persistence prove?
Only the selected configuration’s recovery behavior, after it has been exercised. Replication, snapshots and AOF have separate failure and recovery trade-offs; none replaces a tested restore.
A hot key concentrates requests or bytes on one key. Striping helps only if increments can be partitioned and the read can combine the stripes under an acceptable consistency contract.
A global counter can be split into several counters, but a read now fans out and reset/window boundaries need definition. In Redis Cluster, independent untagged keys can map to different slots; a shared hash tag such as {tenant} forces every stripe for that tenant into one slot. Verify placement when distribution matters, and aggregate across slots in the client or with an explicit routing design.
Measure per-key skew and command latency before sharding, batching or caching locally. A distribution workaround can move cost into aggregation and correctness.
Redis CLI sketch · Worked example
INCR hits:tenant:stripe:0
INCR hits:tenant:stripe:1
# Independent untagged keys may map to different cluster slots.
# Aggregate a bounded, fixed set of stripes client-side.
Illustrative Redis command or pseudocode; untagged keys can distribute across slots but placement is not guaranteed and was not checked on a cluster.
Illustrative, not executed.
Follow-up: When does striping a counter help?
When increments can be spread and reads can tolerate a defined aggregation step. Exact instantaneous values and reset semantics may make that approach unsuitable.
A lock lease can expire while its client is paused. The old client may resume after a new owner acquires the lock, so the protected resource needs fencing or idempotency.
A random token lets the owner release only its own lock; it does not stop stale work from writing elsewhere. A monotonically increasing fencing token is useful only when the downstream resource checks and rejects older tokens.
A single-primary lock also has a failover hazard: with asynchronous replication, the primary can acknowledge SET and fail before the lock reaches its replica. After promotion, another client can acquire the same lock while the first client still acts. A random token lets the owner release only its own lock; it does not stop stale work or repair a lost lock write. A monotonically increasing fencing token helps only when the downstream resource checks and rejects older tokens. Use database constraints or transactions for database invariants, and treat Redis locks as coordination with explicit topology, lease, failure and recovery behavior.
Redis CLI sketch · Worked example
SET lock:job-17 random-token NX PX 30000
# Release only if the stored token still matches.
Illustrative Redis command or pseudocode; no Redis server was used.
Illustrative, not executed.
Follow-up: Why is an expiring lock not proof of exclusive ownership?
A paused client can resume after its lease expires, and asynchronous primary failover can lose an acknowledged lock before its TTL. Fence writes at the protected resource or make effects idempotent; do not rely on a single-primary Redis lock for a database invariant.
Pub/Sub is transient notification; disconnected subscribers miss messages. Streams retain entries and consumer groups track pending work, but the application still owns recovery and idempotency.
A consumer can perform an effect and crash before acknowledging, causing a retry and duplicate effect. Acknowledge after success, reclaim abandoned pending entries under a defined idle policy, and make the handler idempotent.
Set retention and trimming behavior. A data structure alone does not define poison-message handling, dead-lettering, shutdown, delivery semantics or operational limits.
Redis CLI sketch · Worked example
XADD jobs * type email recipient user-7
# XREADGROUP returns each delivered entry together with its actual ID.
message = XREADGROUP GROUP workers c-1 BLOCK 5000 STREAMS jobs >
process(message)
XACK jobs workers message.id # use the ID returned by XREADGROUP
Illustrative Redis command or pseudocode; the consumer acknowledges the ID returned with the message, not a separately guessed literal. No Redis server was used.
Illustrative, not executed.
Follow-up: What should happen after a consumer crashes?
Recover pending work after a defined idle period, then retry idempotently and acknowledge only after success. Specify poison-item and retention behavior.
These are Hacker News job posts that mention these technologies, not employee earnings or a measure of what a skill adds to pay. The amounts summarize annualized advertised minimums in approximate USD. Groups can overlap and differ in roles, locations and dates.
Approximate USD using ECB daily reference rates as of 2026-10-09. Original currencies and offer ranges remain on the source listings. These figures cover posts tagged Redis, rather than every job in the broader technology family.