stock counter کو ایک ہی atomic جگہ رکھیں اور اسے atomically کم کریں — ایک 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 left" نہیں پڑھ سکتیں۔ ایک 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 میں کرنے سے دو requests دونوں 1000 پڑھ لیتی ہیں اور دونوں بیچ دیتی ہیں — کلاسک oversell۔ "اچھا" یہ ہے کہ "transaction / SELECT ... FOR UPDATE استعمال کرو"؛ "عمدہ" یہ پہچاننا ہے کہ row locks 10 لاکھ requests کو ایک ہی hot row پر serialize کر دیتے ہیں اور throughput گرا دیتے ہیں، لہٰذا آپ contention کو Redis میں ایک single-threaded atomic op پر منتقل کرتے ہیں اور صرف winners کو persist کرتے ہیں۔ جال یہ ہے کہ application-level checks (if (stock > 0)) پر atomicity کے بغیر بھروسہ کیا جائے۔
FOR UPDATE: Redis ایک hot key پر 100k+ ops/s سنبھالتا ہے؛ ایک Postgres row lock serialize کرتا ہے اور flash sale کے تحت پگھل جاتا ہے۔ DB کو durable order records کے لیے محفوظ رکھیں۔تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں