Caching hard
You are designing a Lua script for Redis Cluster to atomically move money between two users: `user:A` and `user:B`. Why might this fail?
- A Server-side Lua scripts are fundamentally unsupported in a Redis Cluster environment due to the lack of cross-node execution support.
- B Global transaction atomicity is an impossible architectural goal for any NoSQL system that utilizes a sharded, multi-master topology.
- C If the keys hash to different Hash Slots located on different physical nodes, the operation is a 'Cross-Slot' call and is rejected by the cluster.
- D Redis Cluster does not support the internal floating-point arithmetic required to perform accurate financial calculations within a script.
Answer: C. If the keys hash to different Hash Slots located on different physical nodes, the operation is a 'Cross-Slot' call and is rejected by the cluster.
Redis Cluster uses **Hash Slots** (0-16383) to shard data. Keys are assigned to slots. Operations involving multiple keys (like Lua scripts or `MGET`) generally fail if the keys belong to different slots, because those slots might live on different physical servers. To fix this, you use **Hash Tags** (e.g., `{user:100}.balance` and `{user:100}.history`) to force keys into the same slot.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?