stock counter एकाच atomic ठिकाणी ठेवा आणि atomically decrement करा — एक Redis DECR (किंवा Lua script) जे उरलेले मूल्य return करते. जर निकाल < 0 असेल, तर ती रिक्वेस्ट हरली; database कधीही concurrency gate नसते. बाकी सर्व म्हणजे उरलेल्या 9,99,000 रिक्वेस्ट स्वस्तात 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 आहे — दोन रिक्वेस्ट दोन्ही "1 उरले" वाचू शकत नाहीत. एक Lua script एका round trip मध्ये करते: उरलेले तपासा, decrement करा, आणि SADD winners:{sale} {user} record करा जेणेकरून एक युजर दोनदा जिंकू शकणार नाही. Lua Redis वर single-threaded चालते, त्यामुळे संपूर्ण check-and-set एकच atomic पायरी आहे.>= 0) queue कडे push केले जातात; एक worker order Postgres मध्ये asynchronously लिहितो. DB ला कधीही 10 लाख concurrent writes दिसत नाहीत — फक्त ~1000 winner writes.मुलाखत घेणारा तुम्ही race condition नेमकेपणाने नावाने सांगता का हे पाहू इच्छितो: SELECT stock नंतर UPDATE अशा दोन statements मध्ये दोन रिक्वेस्ट दोन्ही 1000 वाचून दोन्ही विकतात — classic oversell. "चांगले" म्हणजे "transaction / SELECT ... FOR UPDATE वापरा"; "उत्तम" म्हणजे हे ओळखणे की row locks 10 लाख रिक्वेस्ट एका hot row वर serialize करतात आणि throughput कोसळवतात, म्हणून तुम्ही contention Redis मधील single-threaded atomic op कडे हलवता आणि फक्त विजेते 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 मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या