Hold lagertelleren på ett atomisk sted og dekrementer den atomisk — en Redis DECR (eller et Lua-skript) som returnerer gjenværende verdi. Hvis resultatet er < 0, tapte den requesten; databasen er aldri concurrency-porten. Alt annet handler om å kaste av de andre 999 000 requestene billig.
1M klienter ─▶ CDN/edge (venterom, dropp bots) ─▶ LB
│
Stateless API-pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
enqueue order ─▶ DB avvis "utsolgt"
DECR stock:sale123 er atomisk — ingen to requester kan begge lese "1 igjen". Et Lua-skript gjør det i én round trip: sjekk gjenværende, dekrementer, og registrer SADD winners:{sale} {user} slik at én bruker ikke kan vinne to ganger. Lua kjører single-threaded på Redis, så hele check-and-set er ett atomisk steg.>= 0) skyves til en kø; en worker skriver ordren til Postgres asynkront. DB-en ser aldri 1M samtidige writes — bare ~1000 vinner-writes.Intervjueren vil se at du navngir race condition presist: SELECT stock deretter UPDATE i to setninger lar to requester begge lese 1000 og begge selge — klassisk oversalg. "Bra" er "bruk en transaksjon / SELECT ... FOR UPDATE"; "utmerket" er å erkjenne at row locks serialiserer 1M requester på én hot row og kollapser throughput, så du flytter contention til en single-threaded atomisk operasjon i Redis og persisterer kun vinnere. Fellen er å stole på sjekker på applikasjonsnivå (if (stock > 0)) uten atomitet.
FOR UPDATE: Redis håndterer 100k+ ops/s på én hot key; en Postgres row lock serialiserer og smelter under et flash-salg. Reserver DB-en for varige ordreposter.Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner