Mantieni il contatore dello stock in un unico punto atomico e decrementalo atomicamente: un DECR di Redis (o uno script Lua) che restituisce il valore residuo. Se il risultato è < 0, quella richiesta ha perso; il database non è mai il gate della concorrenza. Tutto il resto riguarda lo scaricare le altre 999.000 richieste a basso costo.
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 è atomico: due richieste non possono entrambe leggere "ne resta 1". Uno script Lua lo fa in un solo round trip: verifica il residuo, decrementa e registra SADD winners:{sale} {user} così che un utente non possa vincere due volte. Lua gira single-thread su Redis, quindi l'intero check-and-set è un unico passo atomico.>= 0) vengono inviati a una coda; un worker scrive l'ordine su Postgres in modo asincrono. Il DB non vede mai 1M di scritture concorrenti, solo ~1000 scritture di vincitori.L'intervistatore vuole vederti nominare con precisione la race condition: SELECT stock seguito da UPDATE in due istruzioni permette a due richieste di leggere entrambe 1000 e di vendere entrambe, il classico oversell. "Buono" è "usa una transazione / SELECT ... FOR UPDATE"; "eccellente" è riconoscere che i row lock serializzano 1M di richieste su un'unica riga calda facendo collassare il throughput, per cui sposti la contesa su un'operazione atomica single-thread in Redis e persisti solo i vincitori. La trappola è fidarsi di controlli a livello applicativo (if (stock > 0)) senza atomicità.
FOR UPDATE: Redis gestisce 100k+ operazioni/s su una singola chiave calda; un row lock di Postgres serializza e cede sotto una flash sale. Riserva il DB ai record d'ordine durevoli.Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona