เก็บ counter ของ stock ไว้ใน จุดเดียวที่เป็น atomic และลดค่าลงแบบ atomic — ใช้ Redis DECR (หรือ Lua script) ที่คืนค่าที่เหลืออยู่ ถ้าผลลัพธ์ < 0 แสดงว่า request นั้นแพ้ database จะ ไม่มีวัน เป็นด่านควบคุม concurrency ส่วนที่เหลือทั้งหมดคือเรื่องการทิ้ง request อีก 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 เป็น atomic — ไม่มีทางที่ request สองอันจะอ่านเจอ "เหลือ 1" พร้อมกัน Lua script ทำทั้งหมดใน round trip เดียว: ตรวจค่าที่เหลือ ลดค่า และบันทึก SADD winners:{sale} {user} เพื่อไม่ให้ผู้ใช้คนเดียวชนะสองครั้ง Lua ทำงานแบบ single-threaded บน Redis ดังนั้นทั้ง check-and-set จึงเป็นขั้นตอน atomic เดียว>= 0) ถูก push เข้า queue จากนั้น worker เขียน order ลง Postgres แบบ asynchronous DB ไม่เคยเจอการเขียนพร้อมกัน 1 ล้านครั้ง — มีแค่การเขียนของผู้ชนะประมาณ 1000 รายผู้สัมภาษณ์อยากเห็นคุณระบุ race condition ได้อย่างแม่นยำ: SELECT stock แล้ว UPDATE ในสองคำสั่งทำให้ request สองอันอ่านเจอ 1000 ทั้งคู่และขายทั้งคู่ — oversell แบบคลาสสิก "ดี" คือ "ใช้ transaction / SELECT ... FOR UPDATE" "เยี่ยม" คือตระหนักว่า row lock จะ serialize request 1 ล้านรายลงบน row ร้อนอันเดียวและทำให้ throughput พังทลาย ดังนั้นคุณย้าย contention ไปยัง atomic op แบบ single-threaded ใน Redis แล้ว persist เฉพาะผู้ชนะ กับดักคือการเชื่อการตรวจสอบระดับ application (if (stock > 0)) โดยไม่มี atomicity
FOR UPDATE: Redis รองรับ 100k+ ops/s บน hot key เดียว ส่วน Postgres row lock จะ serialize และละลายภายใต้ flash sale เก็บ DB ไว้สำหรับ record ของ order ที่ต้อง durableคลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค