Ține contorul de stoc într-un singur loc atomic și decrementează-l atomic — un DECR în Redis (sau un script Lua) care returnează valoarea rămasă. Dacă rezultatul este < 0, acel request a pierdut; baza de date nu este niciodată poarta de concurență. Restul înseamnă să scapi ieftin de celelalte 999.000 de request-uri.
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 este atomic — două request-uri nu pot citi ambele "a mai rămas 1". Un script Lua face totul într-un singur round trip: verifică restul, decrementează și înregistrează SADD winners:{sale} {user}, astfel încât un utilizator să nu poată câștiga de două ori. Lua rulează single-threaded pe Redis, deci întregul check-and-set este un singur pas atomic.>= 0) sunt împinși într-o coadă; un worker scrie comanda în Postgres asincron. DB-ul nu vede niciodată 1M de scrieri concurente — doar ~1000 de scrieri de câștigători.Intervievatorul vrea să te vadă numind precis race condition-ul: SELECT stock apoi UPDATE în două instrucțiuni permite ambelor request-uri să citească 1000 și ambelor să vândă — supravânzare clasică. "Bine" este "folosește o tranzacție / SELECT ... FOR UPDATE"; "excelent" este să recunoști că lock-urile pe rânduri serializează 1M de request-uri pe un singur rând fierbinte și prăbușesc throughput-ul, așa că muți concurența pe o operație atomică single-threaded în Redis și persiști doar câștigătorii. Capcana este să te bazezi pe verificări la nivel de aplicație (if (stock > 0)) fără atomicitate.
FOR UPDATE: Redis gestionează 100k+ operații/s pe o cheie fierbinte; un lock pe rând în Postgres serializează și se topește sub un flash sale. Rezervă DB-ul pentru înregistrări durabile ale comenzilor.O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează