stock counter-কে একটি atomic জায়গায় রাখুন এবং atomically decrement করুন — একটি Redis DECR (বা একটি Lua script) যা অবশিষ্ট মান রিটার্ন করে। ফলাফল যদি < 0 হয়, সেই request হেরেছে; database কখনও concurrency gate নয়। বাকি সবকিছু হলো অন্য ৯,৯৯,০০০ request-কে সস্তায় ঝেড়ে ফেলা নিয়ে।
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 — কোনো দুটি request একসাথে "১টি বাকি" পড়তে পারে না। একটি Lua script এটি এক round trip-এ করে: অবশিষ্ট চেক করে, decrement করে, এবং SADD winners:{sale} {user} রেকর্ড করে যাতে একজন ইউজার দুবার জিততে না পারে। Lua Redis-এ single-threaded চলে, তাই পুরো check-and-set একটি atomic ধাপ।>= 0) একটি queue-তে push হয়; একটি worker order-টি asynchronously Postgres-এ লেখে। DB কখনও ১০ লক্ষ concurrent write দেখে না — কেবল ~১০০০ বিজয়ীর write।ইন্টারভিউয়ার দেখতে চান আপনি race condition-টি নির্ভুলভাবে নাম ধরে বলছেন কিনা: দুটি statement-এ SELECT stock তারপর UPDATE দুটি request-কে উভয়ে ১০০০ পড়তে এবং উভয়ে বিক্রি করতে দেয় — ক্লাসিক oversell। "ভালো" হলো "transaction / SELECT ... FOR UPDATE ব্যবহার করুন"; "দারুণ" হলো এটি বোঝা যে row lock ১০ লক্ষ request-কে একটি hot row-এর উপর serialize করে এবং throughput ধসিয়ে দেয়, তাই আপনি contention-টি Redis-এ একটি single-threaded atomic op-এ সরিয়ে নেন এবং কেবল বিজয়ীদের persist করেন। ফাঁদটি হলো atomicity ছাড়া application-level check (if (stock > 0))-এর উপর ভরসা করা।
FOR UPDATE: Redis একটি hot key-এ ১ লক্ষ+ ops/s সামলায়; একটি Postgres row lock serialize করে এবং flash sale-এ গলে যায়। DB-কে durable order record-এর জন্য রাখুন।বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন