Halte den Bestandszähler an einer einzigen atomaren Stelle und dekrementiere ihn atomar - ein Redis DECR (oder ein Lua-Skript), das den verbleibenden Wert zurückgibt. Ist das Ergebnis < 0, hat dieser Request verloren; die Datenbank ist niemals das Concurrency-Gate. Alles Übrige besteht darin, die anderen 999.000 Requests günstig abzuwehren.
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 ist atomar - keine zwei Requests können beide "1 übrig" lesen. Ein Lua-Skript erledigt es in einem Round-Trip: verbleibenden Wert prüfen, dekrementieren und SADD winners:{sale} {user} protokollieren, damit ein Nutzer nicht zweimal gewinnt. Lua läuft single-threaded auf Redis, sodass das gesamte Check-and-Set ein atomarer Schritt ist.>= 0) werden in eine Queue geschoben; ein Worker schreibt die Bestellung asynchron nach Postgres. Die DB sieht nie 1 Mio. gleichzeitige Writes - nur ~1000 Gewinner-Writes.Der Interviewer möchte sehen, dass du die Race Condition präzise benennst: SELECT stock und dann UPDATE in zwei Statements erlaubt es zwei Requests, beide 1000 zu lesen und beide zu verkaufen - der klassische Oversell. "Gut" ist "eine Transaktion / SELECT ... FOR UPDATE verwenden"; "hervorragend" ist zu erkennen, dass Row Locks 1 Mio. Requests auf eine einzige Hot Row serialisieren und den Throughput kollabieren lassen - deshalb verlagerst du die Contention in eine single-threaded atomare Operation in Redis und persistierst nur die Gewinner. Die Falle ist, Prüfungen auf Anwendungsebene (if (stock > 0)) ohne Atomizität zu vertrauen.
FOR UPDATE: Redis bewältigt 100k+ Ops/s auf einem Hot Key; ein Postgres Row Lock serialisiert und schmilzt unter einem Flash Sale. Reserviere die DB für langlebige Bestelldatensätze.Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden