SeniorHazelcast
Flash-sale stock in a near-cached map
Stock counts are read through a near cache and updated with get then put.
The setup today
A client-server Hazelcast cluster holds stock counts per SKU. App instances read stock through a near cache, and when someone buys, they read the count, subtract one and put it back.
Current configuration
map: stock backup-count: 1
client near cache: invalidate-on-change=true
purchase: v = stock.get(sku); stock.put(sku, v - 1)What you know
- A flash sale is planned: 5,000 units, 50,000 stock reads a second.
- Last month's smaller sale oversold by 37 units.
The new requirement
The business says the flash sale must never oversell, even if the cluster has network problems. Showing stock that is a second old is fine; selling stock that does not exist is not.
Make the call
2 questions · first-try answers earn the most XP
What a strong answer also covers
- Split-brain protection detects a split after a short delay; a few operations can still slip through, so reconcile against the order database.
- Hot SKUs make one partition hot; entry processors run on that partition's thread, so measure the throughput of one key.
- Record each sale with an order ID so a retried purchase cannot decrement twice.
- For absolute guarantees, the CP Subsystem's Raft-based structures (configured with CP members, not unsafe mode) or a database transaction are the stronger tools.