Mantenha o contador de estoque em um único lugar atômico e decremente-o atomicamente — um DECR do Redis (ou um script Lua) que retorna o valor restante. Se o resultado for < 0, aquela requisição perdeu; o banco de dados nunca é o portão de concorrência. Todo o resto trata de descartar as outras 999.000 requisições 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 é atômico — não há como duas requisições lerem ambas "resta 1". Um script Lua faz tudo em uma única ida e volta: verifica o restante, decrementa e registra SADD winners:{sale} {user} para que um usuário não possa ganhar duas vezes. Lua roda single-threaded no Redis, então todo o check-and-set é um único passo atômico.>= 0) são empurrados para uma fila; um worker grava o pedido no Postgres de forma assíncrona. O DB nunca vê 1M de escritas concorrentes — apenas ~1000 escritas de vencedores.O entrevistador quer ver você nomear a race condition com precisão: SELECT stock e depois UPDATE em duas instruções permite que duas requisições leiam ambas 1000 e ambas vendam — o clássico oversell. "Bom" é "usar uma transação / SELECT ... FOR UPDATE"; "excelente" é reconhecer que row locks serializam 1M de requisições em uma única linha quente e derrubam o throughput, então você move a contenção para uma operação atômica single-threaded no Redis e persiste apenas os vencedores. A armadilha é confiar em verificações no nível da aplicação (if (stock > 0)) sem atomicidade.
FOR UPDATE do DB: o Redis lida com 100k+ ops/s em uma chave quente; um row lock do Postgres serializa e derrete sob uma flash sale. Reserve o DB para registros duráveis de pedidos.Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar