Gardez le compteur de stock dans un seul endroit atomique et décrémentez-le atomiquement — un DECR Redis (ou un script Lua) qui retourne la valeur restante. Si le résultat est < 0, cette requête a perdu ; la base de données n'est jamais le point de contrôle de la concurrence. Tout le reste consiste à écarter à bas coût les 999 000 autres requêtes.
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 est atomique — deux requêtes ne peuvent pas lire toutes deux « 1 restant ». Un script Lua le fait en un seul aller-retour : vérifier le restant, décrémenter, et enregistrer SADD winners:{sale} {user} pour qu'un utilisateur ne puisse pas gagner deux fois. Lua s'exécute en mono-thread sur Redis, donc l'ensemble check-and-set est une seule étape atomique.>= 0) sont poussés dans une queue ; un worker écrit la commande dans Postgres de manière asynchrone. La DB ne voit jamais 1M d'écritures concurrentes — seulement ~1000 écritures de gagnants.L'examinateur veut vous voir nommer la race condition avec précision : SELECT stock puis UPDATE en deux instructions laisse deux requêtes lire toutes deux 1000 et vendre toutes deux — la survente classique. « Bien » c'est « utiliser une transaction / SELECT ... FOR UPDATE » ; « excellent » c'est reconnaître que les verrous de ligne sérialisent 1M de requêtes sur une seule ligne chaude et effondrent le throughput, donc vous déplacez la contention vers une opération atomique mono-thread dans Redis et ne persistez que les gagnants. Le piège est de se fier aux vérifications applicatives (if (stock > 0)) sans atomicité.
FOR UPDATE : Redis gère 100k+ ops/s sur une seule clé chaude ; un verrou de ligne Postgres sérialise et fond sous une vente flash. Réservez la DB aux enregistrements de commandes durables.Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don