Um sistema distribuído onde cada assento tem 30 segundos para ser comprado — e nenhum milissegundo de margem para erro.
Imagine um cinema com 500 pessoas olhando o mesmo assento A1 da pré-estreia de Interestelar. Às 19:00:00.000, dois dedos clicam "Reservar" exatamente ao mesmo tempo.
Sem controle, os dois recebem "Reservado com sucesso". Dois ingressos, um assento. Um deles chega no cinema e descobre que o lugar é de outra pessoa.
Esse é o problema de race condition — e é o problema que esse sistema resolve.
O sistema foi dividido em personagens com responsabilidades únicas. Nenhum deles sabe como o outro funciona por dentro — só conhecem o contrato (a interface). Se um trocar de implementação, os outros nem percebem.
Cada ingresso percorre um caminho preciso — da criação da sessão até o registro permanente da venda. Qualquer falha no meio do caminho resulta em rollback automático.
Quando alguém reserva um assento, o relógio começa a contar. O Redis segura o lock, o Consumer assiste. Se o pagamento não chegar em 30 segundos, tudo é desfeito automaticamente — o assento volta ao mercado como se nada tivesse acontecido.
O Consumer recebe o evento reservation.created, calcula quanto falta pro expiresAt, espera o tempo exato, e verifica se ainda está PENDING. Se sim: expira tudo. Se o pagamento já chegou: ignora. Sem cron job, sem polling — o consumer já sabe quem vai expirar e quando.
Nenhuma ferramenta foi escolhida por moda. Cada uma resolve um problema específico que as outras não conseguem resolver sozinhas.
Três camadas de teste que se complementam: unitários isolam a lógica sem I/O, contracts validam os status codes via HTTP real, e flows testam fluxos completos incluindo race condition e expiração automática. Tudo roda em 3.7 segundos — sem Docker, sem banco, sem Redis.
Cada PR foi construída em cima da anterior, numa ordem pensada para que o módulo anterior validasse o funcionamento antes do próximo ser construído. Nenhuma dependência circular, nenhum retrabalho.