Simpan counter stok di satu tempat atomik dan kurangi (decrement) secara atomik — sebuah Redis DECR (atau Lua script) yang mengembalikan nilai sisa. Jika hasilnya < 0, request itu kalah; database tidak pernah menjadi gerbang concurrency. Selebihnya adalah soal membuang 999.000 request lainnya secara murah.
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 bersifat atomik — tidak ada dua request yang bisa keduanya membaca "sisa 1". Sebuah Lua script melakukannya dalam satu round trip: cek sisa, decrement, dan catat SADD winners:{sale} {user} agar satu pengguna tidak bisa menang dua kali. Lua berjalan single-threaded di Redis, sehingga seluruh check-and-set adalah satu langkah atomik.>= 0) didorong ke queue; sebuah worker menulis order ke Postgres secara asinkron. DB tidak pernah melihat 1 juta write bersamaan — hanya ~1000 write pemenang.Pewawancara ingin melihat Anda menyebut race condition secara tepat: SELECT stock lalu UPDATE dalam dua statement memungkinkan dua request keduanya membaca 1000 dan keduanya menjual — oversell klasik. "Baik" adalah "gunakan transaksi / SELECT ... FOR UPDATE"; "hebat" adalah menyadari bahwa row lock menserialisasi 1 juta request ke satu baris panas dan meruntuhkan throughput, sehingga Anda memindahkan kontensi ke satu operasi atomik single-threaded di Redis dan hanya mem-persist pemenang. Jebakannya adalah memercayai pengecekan di level aplikasi (if (stock > 0)) tanpa atomicity.
FOR UPDATE: Redis menangani 100k+ ops/s pada satu hot key; row lock Postgres menserialisasi dan meleleh di bawah flash sale. Cadangkan DB untuk record order yang durable.Perpustakaan pertanyaan wawancara IT dengan jawaban mendetail — dari Junior hingga Senior.
Donasi