Simpen counter stok ing siji panggonan atomik lan kurangi kanthi atomik — Redis DECR (utawa skrip Lua) sing mbalekake nilai sisa. Yen asile < 0, request kuwi kalah; database ora tau dadi gerbang concurrency. Sisane kabeh yaiku babagan mbuwang 999.000 request liyane kanthi 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 iku atomik — ora ana loro request sing bisa padha-padha maca "kari 1". Skrip Lua nindakake iki ing sawijining round trip: mriksa sisa, ngurangi, lan nyathet SADD winners:{sale} {user} supaya siji pangguna ora bisa menang kaping pindho. Lua mlaku single-threaded ing Redis, mula kabeh check-and-set dadi siji langkah atomik.>= 0) didorong menyang antrian; sawijining worker nyerat order menyang Postgres kanthi asinkron. DB ora tau ndeleng 1 yuta tulisan bebarengan — mung ~1000 tulisan pemenang.Pewawancara pengin ndeleng sampeyan nyebutake race condition kanthi tliti: SELECT stock banjur UPDATE ing rong statement nglilani loro request padha-padha maca 1000 lan padha-padha adol — oversell klasik. "Apik" yaiku "nganggo transaksi / SELECT ... FOR UPDATE"; "apik banget" yaiku ngerteni yen row lock nyerialake 1 yuta request menyang siji row panas lan njeblug throughput, mula sampeyan mindhah contention menyang operasi atomik single-threaded ing Redis lan mung nyimpen pemenang. Jebakane yaiku percaya marang pamriksan ing level aplikasi (if (stock > 0)) tanpa atomicity.
FOR UPDATE: Redis nangani 100rb+ ops/s ing siji hot key; row lock Postgres nyerialake lan lebur sajrone flash sale. Cadhangno DB kanggo cathetan order sing tahan lama (durable).Pustaka pitakon wawancara IT kanthi jawaban rinci — saka Junior nganti Senior.
Nyumbang