SeniorRedis
Moving a checkout script to Redis Cluster
A Lua script touches a user's cart and a global stock counter. Now it must run on a cluster.
The setup today
Checkout reserves stock with one Lua script on a single Redis primary. The script reads the user's cart, writes a reservation for the user, and decrements a stock counter for each item. Because Redis runs a script atomically, there are no races today.
Current configuration
EVALSHA reserve 3 cart:42 hold:42 stock:sku-981 ...
# keys: cart:<user>, hold:<user>, stock:<sku>
redis 7, single primary + 1 replicaWhat you know
- Peak load is 40,000 commands a second today and expected to reach 200,000.
- A few hundred SKUs account for most sales during promotions.
- Stock must never go below zero.
The new requirement
The platform team is moving to Redis Cluster with six primaries to handle five times the traffic. The checkout script must keep working, and stock must still never be oversold.
Make the call
2 questions · first-try answers earn the most XP
What a strong answer also covers
- Hot SKUs during a promotion are hot keys: one node takes all their decrements. Consider splitting stock into several sub-counters per SKU.
- Make each step idempotent with a checkout ID, so a retry after a timeout cannot reserve twice.
- If stock must never be oversold, the database (or a store with stronger guarantees) should hold the final truth; Redis failover can lose the newest writes.
- Load-test the new script path against a cluster before switching, including a resharding during the test.