احتفظ بعدّاد المخزون في مكان ذرّي واحد (atomic) وأنقِصه ذرّياً — عملية DECR في Redis (أو سكربت Lua) تُعيد القيمة المتبقّية. إذا كانت النتيجة < 0 فقد خسر ذلك الطلب؛ قاعدة البيانات ليست أبداً بوّابة التزامن (concurrency gate). كل ما تبقّى يدور حول التخلّص من الـ 999,000 طلب الأخرى بثمن زهيد.
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 ذرّي — لا يمكن لطلبين أن يقرأا معاً "بقي 1". يقوم سكربت Lua بذلك في جولة واحدة: يفحص المتبقّي، ويُنقص، ويسجّل SADD winners:{sale} {user} كي لا يفوز المستخدم مرتين. يعمل Lua على Redis بخيط واحد (single-threaded)، فتكون عملية الفحص والتعيين كلها خطوة ذرّية واحدة.>= 0) إلى طابور؛ ويكتب عامل الطلب إلى Postgres بشكل غير متزامن. لا ترى قاعدة البيانات مليون كتابة متزامنة أبداً — بل نحو 1000 كتابة للفائزين فقط.يريد المُحاور أن يراك تسمّي حالة السباق (race condition) بدقة: SELECT stock ثم UPDATE في جملتين يتيح لطلبين أن يقرأا معاً 1000 وأن يبيعا معاً — بيع زائد كلاسيكي. "الجيد" هو "استخدم transaction / SELECT ... FOR UPDATE"؛ و"الرائع" هو إدراك أن أقفال الصفوف (row locks) تُسلسِل مليون طلب على صفٍّ ساخن واحد وتُطيح بالـ throughput، لذا تنقل التنافس إلى عملية ذرّية أحادية الخيط في Redis ولا تُثبّت سوى الفائزين. الفخ هو الوثوق بفحوصات على مستوى التطبيق (if (stock > 0)) دون ذرّية.
FOR UPDATE في قاعدة البيانات: يتعامل Redis مع أكثر من 100 ألف عملية/ثانية على مفتاح ساخن واحد؛ بينما قفل صفّ في Postgres يُسلسِل وينهار تحت بيع خاطف. احفظ قاعدة البيانات لسجلات الطلبات المعمّرة (durable).مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع