Mantén el contador de stock en un único lugar atómico y decreméntalo de forma atómica — un DECR de Redis (o un script Lua) que devuelva el valor restante. Si el resultado es < 0, esa request perdió; la base de datos nunca es la barrera de concurrencia. Todo lo demás consiste en descartar las otras 999.000 requests de forma barata.
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 es atómico — dos requests no pueden leer ambas "queda 1". Un script Lua lo hace en un solo round trip: comprueba el restante, decrementa y registra SADD winners:{sale} {user} para que un usuario no pueda ganar dos veces. Lua corre single-threaded en Redis, así que todo el check-and-set es un único paso atómico.>= 0) se empujan a una cola; un worker escribe el pedido en Postgres de forma asíncrona. La DB nunca ve 1M de escrituras concurrentes — solo ~1000 escrituras de ganadores.El entrevistador quiere ver que nombras la race condition con precisión: SELECT stock y luego UPDATE en dos sentencias permite que dos requests lean ambas 1000 y ambas vendan — el clásico oversell. "Bueno" es "usa una transacción / SELECT ... FOR UPDATE"; "excelente" es reconocer que los locks de fila serializan 1M de requests sobre una única fila caliente y colapsan el throughput, así que mueves la contención a una operación atómica single-threaded en Redis y solo persistes a los ganadores. La trampa es confiar en comprobaciones a nivel de aplicación (if (stock > 0)) sin atomicidad.
FOR UPDATE de la DB: Redis maneja 100k+ ops/s sobre una única clave caliente; un lock de fila en Postgres serializa y se derrite bajo una flash sale. Reserva la DB para los registros de pedidos duraderos.Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar