stock counter को एक ही atomic जगह रखें और उसे atomically decrement करें — एक Redis DECR (या एक Lua script) जो बचा हुआ मान लौटाती है। अगर परिणाम < 0 है, तो वह request हार गई; database कभी concurrency gate नहीं होता। बाकी सब बचे हुए 999,000 requests को सस्ते में shed करने के बारे में है।
1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB
│
Stateless API pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
enqueue order ─▶ DB reject "sold out"
DECR stock:sale123 atomic है — कोई दो requests दोनों "1 बचा" नहीं पढ़ सकतीं। एक Lua script यह एक ही round trip में करती है: बचा हुआ चेक करें, decrement करें, और SADD winners:{sale} {user} record करें ताकि एक यूज़र दो बार न जीते। Lua, Redis पर single-threaded चलती है, इसलिए पूरा check-and-set एक atomic step है।>= 0) एक queue में push किए जाते हैं; एक worker order को Postgres में asynchronously लिखता है। DB कभी 10 लाख concurrent writes नहीं देखता — केवल ~1000 winner writes।Interviewer आपको race condition सटीक रूप से बताते देखना चाहता है: SELECT stock फिर UPDATE दो statements में करने से दोनों requests 1000 पढ़ सकती हैं और दोनों बेच सकती हैं — क्लासिक oversell। "अच्छा" है "transaction / SELECT ... FOR UPDATE इस्तेमाल करें"; "बढ़िया" यह पहचानना है कि row locks 10 लाख requests को एक hot row पर serialize कर देते हैं और throughput ध्वस्त कर देते हैं, इसलिए आप contention को Redis के single-threaded atomic op पर ले जाते हैं और केवल winners को persist करते हैं। जाल है atomicity के बिना application-level checks (if (stock > 0)) पर भरोसा करना।
FOR UPDATE: Redis एक hot key पर 100k+ ops/s संभालता है; एक Postgres row lock serialize कर देता है और flash sale में पिघल जाता है। DB को durable order records के लिए बचाकर रखें।विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें