Houd de voorraadteller op één atomaire plek en verlaag hem atomair — een Redis DECR (of een Lua-script) die de resterende waarde teruggeeft. Is het resultaat < 0, dan heeft die request verloren; de database is nooit de concurrency-poort. Al het overige gaat over het goedkoop afvangen van de andere 999.000 requests.
1M clients ─▶ CDN/edge (wachtkamer, bots weren) ─▶ LB
│
Stateless API pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
order in queue ─▶ DB reject "uitverkocht"
DECR stock:sale123 is atomair — geen twee requests kunnen beide "1 over" lezen. Een Lua-script doet het in één round trip: check resterend, verlaag, en registreer SADD winners:{sale} {user} zodat één gebruiker niet twee keer kan winnen. Lua draait single-threaded op Redis, dus de hele check-and-set is één atomaire stap.>= 0) worden in een queue gezet; een worker schrijft de order asynchroon naar Postgres. De DB ziet nooit 1 miljoen gelijktijdige writes — slechts ~1000 winnaar-writes.De interviewer wil je de race condition precies horen benoemen: SELECT stock gevolgd door UPDATE in twee statements laat twee requests beide 1000 lezen en beide verkopen — de klassieke oversell. "Goed" is "gebruik een transactie / SELECT ... FOR UPDATE"; "uitstekend" is inzien dat row locks 1 miljoen requests serialiseren op één hot row en de throughput laten instorten, zodat je de contentie verplaatst naar een single-threaded atomaire operatie in Redis en alleen winnaars persisteert. De valkuil is vertrouwen op checks op applicatieniveau (if (stock > 0)) zonder atomiciteit.
FOR UPDATE: Redis verwerkt 100k+ ops/s op één hot key; een Postgres row lock serialiseert en smelt onder een flash sale. Reserveer de DB voor duurzame orderrecords.Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren