Hold lager-tælleren ét atomart sted og dekrementér den atomart — en Redis DECR (eller et Lua-script), der returnerer den resterende værdi. Hvis resultatet er < 0, tabte den request; databasen er aldrig concurrency-porten. Alt andet handler om at afvise de øvrige 999.000 requests billigt.
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 er atomart — ingen to requests kan begge læse "1 tilbage". Et Lua-script gør det i én round trip: tjek resterende, dekrementér og registrér SADD winners:{sale} {user}, så én bruger ikke kan vinde to gange. Lua kører single-threaded på Redis, så hele check-and-set er ét atomart trin.>= 0) pushes til en queue; en worker skriver ordren til Postgres asynkront. DB'en ser aldrig 1M samtidige writes — kun ~1000 vinder-writes.Intervieweren vil se dig navngive race condition'en præcist: SELECT stock efterfulgt af UPDATE i to statements lader to requests begge læse 1000 og begge sælge — klassisk oversalg. "Godt" er "brug en transaction / SELECT ... FOR UPDATE"; "fremragende" er at erkende, at row locks serialiserer 1M requests på én hot row og kollapser throughput, så du flytter kontentionen til en single-threaded atomar operation i Redis og persisterer kun vindere. Fælden er at stole på checks på applikationsniveau (if (stock > 0)) uden atomicitet.
FOR UPDATE: Redis håndterer 100k+ ops/s på én hot key; en Postgres row lock serialiserer og smelter under et flash sale. Reservér DB'en til holdbare ordre-records.Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér