Redis Cluster Interview Questions: Hash Slots, Multi-Key Operations, and Failover

A cart service works on one Redis instance, then fails after moving to Redis Cluster. Its script updates cart:42:items and cart:42:total, but the server returns CROSSSLOT. Adding replicas does not fix the error. Sending both commands through one connection does not fix it either.

Redis Cluster interview questions test whether you can connect key design, command scope, client routing, and failure recovery. Identify which keys must change together, show their slot mapping, and explain how the caller recovers when ownership changes.

Evidence boundary: Official facts below describe Redis Open Source Cluster using current Redis documentation. Proxy-based Redis products can expose different behavior. The cart examples and recovery decisions are original interview exercises; no candidate reports or employer-frequency claims are used. Slot values were checked with a local CRC16 model, not a running Redis cluster.

What is a hash slot, and how is it different from a node?

Official fact: Redis Cluster divides the keyspace into 16,384 slots. Ordinarily, a key's slot is CRC16(key) mod 16384; a valid hash tag changes the hashed input. Nodes own slot ranges, and the cluster can move ownership without changing the key's slot calculation. Redis Cluster specification.

Worked example: The following values come from the documented CRC16-XMODEM calculation implemented in a local Python check:

Key	Hash input	Slot
cart:42:items	Entire key	6635
cart:42:total	Entire key	11155
cart:{42}:items	42	8000
cart:{42}:total	42	8000
cart:{43}:items	43	3937

The first two keys describe the same cart to a human, but their names provide no colocation contract. The tagged pair does. Cart 43 can live elsewhere, preserving distribution across carts.

Official fact: CLUSTER KEYSLOT key reports the slot for a supplied key. Use it to verify actual serialized key names, including prefixes inserted by a client library. CLUSTER KEYSLOT.

An interviewer may say both untagged keys currently reside on the same node. That still does not make them a valid same-slot operation. A node is a temporary owner of many slots; the command's routing constraint concerns the slot itself. Depending on accidental node placement would make correctness change during resharding.

How should you choose a hash tag for multi-key operations?

Design inference: Use the smallest business group that requires atomic coordination. For a cart, {42} might join items, total, and a short-lived operation record. For a tenant-specific cart, an encoded tenant-and-cart identity avoids collisions between tenants that both have cart 42.

Do not tag every key {all-carts} merely to eliminate CROSSSLOT. That routes the entire workload into one slot. Adding nodes cannot distribute that slot's ordinary ownership across several primaries at once. The convenience of global atomic access would consume the sharding benefit you introduced Cluster to obtain.

Write a key contract before implementing the script:

cart:{tenant7/cart42}:items
cart:{tenant7/cart42}:total
cart:{tenant7/cart42}:operation:request9

Official fact: Hash-tag parsing uses the first opening brace and the first following closing brace, and requires nonempty content between them. Empty braces do not supply a valid tag. Hash-tag rules.

Implementation inference: Encode user-controlled identifiers before placing them inside the tag. An unexpected brace in a raw identifier could change what gets hashed. Test the exact keys emitted by every language client; a shared naming convention is useful only when the bytes agree.

Then challenge the grouping. If checkout must also modify a global inventory key, a cart tag does not magically colocate every product and cart. Either redesign the data grouping, accept a coordinated multi-step workflow, or put the authoritative invariant in a system that supports the required transaction. Name that tradeoff explicitly.

Does MULTI, pipelining, or Lua remove the slot restriction?

Official fact: Redis transactions queue commands and execute the queued sequence without another client's commands interleaving. They do not provide SQL-style rollback for command errors during execution. WATCH supports an optimistic check that can abort execution when watched data changes. Redis transactions.

Official fact: Lua scripts execute atomically relative to other server activity and must identify accessed keys through the script's key arguments. Cluster-compatible scripts should keep their accessed keys in one slot. Script execution blocks other activity on the executing server, so long scripts have a latency cost. Scripting with Lua.

Original cart exercise: A script receives the three tagged keys above. It first checks whether request 9 already has a stored outcome. For a new request, it validates inputs, adjusts the cart, and records the result. The shared tag satisfies the placement requirement; the script supplies the no-interleaving boundary.

Those are separate requirements. A same-slot key layout does not make three independent client commands atomic. Conversely, wrapping cross-slot keys in Lua or MULTI does not create a distributed transaction.

A cluster-aware client's pipeline may group independent commands by destination and combine their replies. Treat that as transport optimization, not an all-or-nothing business operation. One node can respond while another connection fails. Check the selected client's documented pipeline behavior rather than assuming one language library's behavior applies to all clients.

Also validate before mutating inside a script. Atomic execution is not an automatic rollback mechanism for an application mistake after earlier writes. Keep the script's error paths and maximum work small enough to explain and test.

What is the difference between MOVED, ASK, and TRYAGAIN?

Official fact: Cluster clients can receive MOVED when routing to an incorrect slot owner. During migration, ASK directs a request temporarily to another node. Multi-key operations can receive TRYAGAIN while their same-slot keys are split across migration states. Cluster redirection and migration.

Official fact: Following an ASK redirect requires sending ASKING before the redirected command on that destination connection. This is a one-command permission, not a permanent change of slot ownership. ASKING.

Original response matrix: Separate a server's routing response from a network failure that obscures execution:

Observation	Client response	Mistake to avoid
CROSSSLOT	Inspect the complete key set and naming contract	Repeating the unchanged invalid operation
MOVED	Follow the owner and refresh relevant topology	Pinning a key permanently to an old node
ASK	Use ASKING and the redirected command on one connection	Replacing the permanent slot map solely because of ASK
TRYAGAIN during migration	Retry with a deadline and bounded backoff	Assuming same-slot keys make every migration moment transparent
Write times out	Determine whether the write may have executed	Replaying an increment as though failure proved non-execution

This is why a generic “retry every exception three times” answer is incomplete. A key-contract bug needs a design correction. A routing response needs protocol handling. An ambiguous write needs operation-level recovery.

A topology refresh also has a cost. During failover, many clients may discover stale routing simultaneously. Bound refresh and retry work so recovery traffic does not amplify the original disruption. Report the final application outcome after the retry budget expires rather than hiding indefinite retries behind a slow request.

Can failover lose a write that Redis already acknowledged?

Official fact: Redis Cluster uses asynchronous replication, so an acknowledged primary write can be lost if the primary fails before an eligible promoted replica receives it. Replicas improve availability; they do not remove every acknowledged-write-loss window. Scaling with Redis Cluster.

Original failure timeline: A cart total is 20 on primary P and replica R. P accepts an increment to 25 and replies successfully. Before R receives the change, P becomes unavailable and R is promoted. A later read from the new primary can return 20.

Now distinguish two application roles. If Redis holds a rebuildable cart projection backed by a durable event log, replay may repair the projection. If Redis is the only authoritative ledger, the same failure has a different consequence. “We have replicas” does not answer which state the business can recover.

Official fact: WAIT waits for a specified number of replica acknowledgments for preceding writes on the connection and returns the number reached. It improves data safety but does not turn Redis into a strongly consistent system. The caller must inspect the returned count. WAIT.

Design inference: Route WAIT to the primary connection that performed the relevant write. If the requested acknowledgment count is not reached by the timeout, the earlier write has not thereby been rolled back. Your response policy must account for that uncertain durability level without blindly applying the mutation again.

Official fact: A Cluster replica can serve reads after a connection enters READONLY mode, accepting that the data may be stale. READONLY.

A cart page may tolerate a stale display; an immediate confirmation of a just-applied operation may require a different read policy. State the requirement first, then choose routing. Even a primary read policy must still account for the failover-loss scenario above.

What should a Redis Cluster failure test prove?

Original test plan: Begin with a tiny cart fixture and record the full key names, computed slots, operation IDs, replies, and final state. A useful test changes one failure condition at a time so the explanation remains attributable.

First, send the untagged pair and confirm the expected slot mismatch. Then use the tagged pair and verify the business mutation. Next move the slot while issuing bounded requests. Assert that the client handles temporary redirects without treating them as permanent ownership changes or multiplying the logical operation.

For failover, use a disposable cluster and deliberately control the replication gap. A casual process restart may preserve all writes and prove little about the acknowledged-write-loss case. Record which replica had the write before promotion, and compare the application's reported success with recovered state afterward.

Finally, lose the response after a successful mutation. A retry must preserve the logical operation ID. If the deduplication record and mutation can both disappear during failover, explain what authoritative record can reconcile them. Colocation solves the local script boundary; it does not create a durability guarantee beyond the underlying replication model.

Practice the key-design and recovery explanation

Practice question	Cluster follow-up
Explain Redis design, persistence, and scaling	Trace slot ownership separately from replication and persistence.
Defend a Redis Choice and Explain Database Index Trade-offs	Defend a Redis choice under the required consistency boundary.
Design a Product Inventory and Pricing Service	Choose a key group for inventory and identify cross-cart conflicts.
Design sliding-window rate limiter with multi-keys	Explain when multi-dimensional quotas need incompatible key groups.
Handle cache-update conflicts in distributed services	Recover an ambiguous mutation without duplicating its effect.

A defensible answer starts with the atomic key group, demonstrates its slot mapping, and then follows the request through migration and failover. Close by stating whether Redis is authoritative or rebuildable and how the application resolves a lost response.

Continue with the Redis interview guide to connect this routing model to data structures, persistence, and hot-key design.

Sources and Further Reading

• Redis Cluster specification: slots, hash tags, and migration responses.
• Scale with Redis Cluster: replication and availability boundaries.
• CLUSTER KEYSLOT: verifying key placement.
• ASKING: temporary redirect handling.
• Redis transactions: execution and error semantics.
• Scripting with Lua: key arguments and atomic execution.
• WAIT: replica acknowledgment limits.
• READONLY: reading from Cluster replicas.