Projetar um Sistema de Reserva de Bilhetes para Vendas Relâmpago de Concertos

Suposições: Os compradores são autenticados antes do checkout, o provedor de pagamento suporta chaves de idempotência e autorização seguida de captura, e a espera de oito minutos é um prazo para concluir uma compra — não uma garantia de que um pagamento iniciado no último segundo será bem-sucedido. A segurança tem precedência sobre a disponibilidade durante uma falha regional ambígua.

Arquitetura: Coloque um CDN e proteção contra bots na frente de uma sala de espera virtual, gateway de API e serviços stateless de mapa de assentos, reserva, pedido e pagamento. Execute os serviços em várias zonas de disponibilidade na região primária, com um standby quente na segunda região; escale os serviços voltados para a venda. Use um banco de dados transacional como autoridade para o estado do assento, retenções, pedidos e limites por usuário. Replique seu estado confirmado de forma síncrona para a região de standby. Publique eventos de outbox do banco de dados em um barramento de mensagens para notificações e atualizações de cache. Sirva mapas de assentos de um cache, com atualizações enviadas aos clientes; a disponibilidade exibida é consultiva, não uma promessa. Mantenha o caminho de gravação crítico independente do cache e do barramento de mensagens.

Retenções e compras: Dê a cada par evento-assento uma linha de banco de dados. Uma solicitação de retenção bloqueia o registro de limite por evento do comprador e as linhas de assento solicitadas em uma ordem consistente, verifica se o comprador reterá no máximo seis assentos e reivindica atomicamente assentos que estão disponíveis ou cujas retenções expiraram. Armazene o proprietário da retenção, o token e a expiração usando o tempo do banco de dados. Retorne conflitos sem sucesso parcial, a menos que o cliente aceite explicitamente menos assentos. Nem as entradas de cache nem um temporizador decidem a propriedade: cada retenção e compra concorrente verifica a linha autoritativa em uma transação. Um worker expira retenções para atualizações rápidas do mapa, enquanto leituras e gravações também tratam retenções expiradas como disponíveis, para que um worker com falha não possa deixar assentos presos.

No checkout, crie uma tentativa de pedido durável vinculada à retenção e a uma chave de idempotência. Após a autorização de pagamento ser definitivamente bem-sucedida, altere atomicamente os assentos para VENDIDOS e o pedido para CONFIRMADO somente se cada assento ainda pertencer a essa retenção e não tiver expirado. Confirme a confirmação e seu evento de outbox juntos. Capture o pagamento após a confirmação; retente capturas falhas e reconcilie-as operacionalmente. Se a confirmação perder a corrida para a expiração, anule ou reembolse a autorização. Um assento vendido nunca se torna disponível novamente por expiração de retenção. Retentativas do cliente usam a mesma chave de tentativa e recuperam o resultado existente em vez de criar outra compra.

Tráfego de abertura de venda e justiça: Admita usuários através da sala de espera a uma taxa limitada pela capacidade medida do banco de dados e de pagamento, não pelo número de servidores web. Aleatorize as posições entre os usuários presentes antes da abertura anunciada, e depois admita os recém-chegados em ordem de chegada. Emita tokens de admissão assinados e de curta duração; aplique limites de compra por conta, desafios de bot e limites de taxa sem permitir que atualizações repetidas melhorem a posição. Mostre estimativas de posição na fila e descarte tráfego não essencial. Armazene em cache a geometria estática do mapa de assentos no CDN e coaleça atualizações de disponibilidade; limite as retenções e checkouts simultâneos. A admissão diminui quando a contenção de bloqueio, o backlog de pagamentos ou as taxas de erro aumentam. Um usuário admitido para navegar não tem prioridade de assento até que uma transação de retenção seja confirmada.

Incerteza de pagamento: Nunca mantenha um bloqueio de banco de dados durante uma chamada de provedor. Use a chave de idempotência do provedor para retentativas e webhooks como evidência para reconciliar autorizações com tempo limite ou incertas; um tempo limite HTTP não é uma recusa. Consulte o provedor antes de outra tentativa e mantenha as tentativas incertas visivelmente pendentes. Não confirme um pedido sem uma autorização definitiva e uma transação de assento bem-sucedida. Se o prazo de oito minutos passar primeiro, os assentos podem ser recuperados; qualquer autorização posterior é anulada ou reembolsada, não transformada em um pedido confirmado. Alerte sobre tentativas não resolvidas e reconcilie com os registros de liquidação do provedor. Desative novos checkouts se a reconciliação for insegura, em vez de arriscar cobranças ou vendas duplicadas.

Confiabilidade e metas: Instâncias multizonais, balanceadores de carga e failover de banco de dados lidam com falhas comuns de nós ou zonas. Serviços stateless podem reiniciar; um cache com falha volta a leituras autoritativas com taxa limitada; um barramento com falha atrasa mapas e notificações, mas não compras. Transações de banco de dados, logs duráveis, replicação síncrona entre regiões antes de confirmar confirmações, backups, testes de restauração e replay de outbox protegem pedidos confirmados. Mantenha o standby quente e teste o failover sob carga de venda. A promoção requer o fencing do antigo gravador e a verificação do progresso replicado: duas regiões sozinhas não podem garantir com segurança gravações imediatas durante uma partição de rede e confirmações zero perdidas. Pause as compras se o fencing ou a replicação forem incertos. Meça 99,95% de disponibilidade do fluxo de compra em uma janela mensal definida, sem excluir falhas de provedor ou falhas de admissão, e orce capacidade e tempo de failover contra isso; uma partição regional suficientemente longa pode violar a meta em vez de permitir overselling.

Compromissos: Use um banco de dados transacional de assentos em vez de bloqueios Redis: maior custo de gravação compra propriedade e pedidos auditáveis e atômicos. Use um gravador com failover com fencing em vez de gravações de assentos ativo-ativo: menor disponibilidade de gravação geográfica, mas sem proprietários conflitantes. Use mapas em cache e ligeiramente desatualizados em vez de leituras de banco de dados para cada visualizador: conflitos podem ocorrer na seleção, mas uma chegada de 500.000 usuários não sobrecarrega a autoridade. Use admissão limitada em vez de escalonamento automático ilimitado: alguns usuários esperam, mas os checkouts admitidos permanecem utilizáveis e a infraestrutura não precisa ser provisionada para todo o surto. Libere retenções expiradas, apesar de pagamentos incertos, em vez de estendê-las indefinidamente: o inventário retorna a tempo, ao custo de cancelamentos ou reembolsos ocasionais.

Painel de vendas e alertas: Rastreie a profundidade da fila, a distribuição do tempo de espera e a taxa de admissão; disponibilidade e latência da API; sucesso de retenção, conflitos, atraso de expiração, falhas de limite por usuário e esperas de bloqueio de banco de dados; conversão de checkout e latência de confirmação de pedido; tempos limite de pagamento, idade de tentativas pendentes, incompatibilidades de autorização para confirmação, reembolsos e falhas de captura. Alerte imediatamente sobre qualquer violação de invariante de assento duplicado ou pedido confirmado perdido; alerte sobre atraso de replicação, fencing falho, baixa capacidade de banco de dados, aumento de taxas 5xx, incerteza excessiva de pagamento e backlog de expiração. Rastreie a desatualização do cache e o atraso do outbox separadamente da saúde de compra autoritativa.

1. Arquitetura de Alto Nível e Armazenamento de Dados: A arquitetura utiliza uma configuração multirregional ativa-passiva (Região Primária A lida com todas as gravações transacionais; a Região B serve como standby quente para recuperação de desastres e tráfego de leitura regional). Fila de Espera Virtual / Edge: Uma camada de CDN (por exemplo, Cloudflare) atua como front-end para todo o tráfego e integra uma fila de espera virtual na borda para absorver o pico inicial de 500 mil usuários. API Gateway: Roteia o tráfego autenticado, executa limitação de taxa e valida tokens de admissão de fila assinados. Serviço de Disponibilidade de Assentos (Caminho de Leitura): Lê o status dos assentos do local a partir de um cache na memória (Redis) e serve instantâneos do mapa de assentos cacheados pela CDN (atualizados a cada 1-2 segundos via SSE ou short-polling). Mecanismo de Retenção e Reserva (Caminho de Gravação): Microsserviços Go/Java executando comandos de reserva de assentos contra uma camada de cache transacional na memória (Redis Cluster) com backup em um banco de dados relacional. Serviço de Pedidos e Pagamentos: Orquestra o ciclo de vida do pedido, cria intenções de pagamento com o provedor de pagamento, escuta webhooks e lida com a reconciliação de status. Armazenamento de Dados: (a) Redis Cluster: Fragmentado por ID do Evento, contém bitmaps de status de assentos e concessões de retenção (TTL: 8 minutos) para bloqueio de assentos em microssegundos. (b) Banco de Dados Relacional (Amazon Aurora PostgreSQL Multi-AZ): O sistema de registro autoritativo para assentos, retenções, pedidos, ingressos e livros-razão financeiros, usando transações ACID para garantir zero overselling. (c) Kafka / SQS: Barramento de mensagens assíncrono para eventos de conclusão de pedido, notificações, geração de PDF de ingressos e reconciliação de pagamentos. 2. Retenções de Assentos, Concorrência e Expiração: O zero overselling é garantido por meio de um modelo de reserva em duas fases. Na Fase 1 (Retenção na Memória), as solicitações de seleção de assentos (até 6 assentos) atingem o Mecanismo de Retenção. Um script Lua do Redis inspeciona atomicamente o estado do bitmask ou hash dos assentos solicitados. Se todos os assentos estiverem 'DISPONÍVEIS', ele os marca como 'RETIDOS', grava um Registro de Retenção contendo {user_id, hold_id, timestamp, seat_ids} e define um TTL rigoroso de 480 segundos. Se algum assento já estiver 'RETIDO' ou 'VENDIDO', o script Lua aborta de forma limpa sem alocação parcial. Na Fase 2 (Retenção no Banco de Dados Autoritativo), um registro de banco de dados idempotente é criado no Aurora dentro de uma única transação: INSERT INTO holds (id, user_id, event_id, seat_ids, expires_at) VALUES (...) e atualiza o status do assento para 'RETIDO'. Tratamento de Expiração: Se o usuário não finalizar a compra em 8 minutos, a retenção do Redis expira por meio de eventos de expiração de chave (Notificações de Keyspace do Redis com backup de um reaper durável em segundo plano que escaneia o Aurora em busca de 'expires_at < NOW() AND status = HELD'). O reaper inverte atomicamente o status do assento de volta para 'DISPONÍVEL' no Aurora e restaura o bitmask do Redis, liberando instantaneamente os assentos para compradores ativos. Finalização da Compra: Após a confirmação do pagamento, uma transação ACID no Aurora atualiza os assentos para 'VENDIDOS', marca o pedido como 'PAGO', gera registros de ingressos imutáveis e atualiza o status do assento no Redis para 'VENDIDO'. 3. Pico de Tráfego, Controle de Admissão e Justiça: Lidar com 500.000 usuários simultâneos em 2 minutos requer controle de admissão agressivo para que os serviços downstream operem estritamente dentro da capacidade. Fila de Espera Virtual na Borda: Usuários que chegam antes e durante a abertura da venda são direcionados para uma Fila de Espera Virtual na Borda leve. Usuários que chegam antes de T-0 são colocados em um pool de pré-venda. Em T-0, a ordem de chegada é randomizada dentro do burst inicial para eliminar vantagens de bots de milissegundos, após o que se aplica a fila FIFO estrita. Admissão com Taxa Limitada: O sistema calcula a taxa de admissão com base no tamanho do local e na capacidade de processamento (por exemplo, admitindo 1.000 usuários a cada 10 segundos). Usuários admitidos recebem um token HMAC criptograficamente assinado contendo {user_id, queue_slot, expires_at} válido para entrada no mapa de assentos interativo e pipeline de checkout. Otimização do Mapa de Assentos: Gerar mapas de 60.000 assentos dinamicamente para 500.000 usuários derrubaria os bancos de dados. Em vez disso, o estado do mapa de assentos é renderizado como um vetor binário compactado ou um chunk delta-JSON cacheados na borda da CDN com um TTL de 1 segundo. Os usuários buscam a geometria estática do local uma vez, depois buscam deltas de status de assento com cache de 1 segundo, mantendo a carga de leitura do backend abaixo de 500 RPS. 4. Integração de Pagamentos e Tratamento de Falhas: Os pagamentos são orquestrados por meio de uma máquina de estados assíncrona. Etapa 1 (Iniciação do Checkout): O usuário entra no fluxo de pagamento; o sistema cria um Pedido interno no estado 'PAGAMENTO_PENDENTE' vinculado ao ID da Retenção. Uma chave de idempotência (order_id + attempt_count) é gerada. Etapa 2 (Interação com Provedor Externo): O frontend coleta os detalhes de pagamento usando SDKs do lado do cliente do provedor (cartões tokenizados) e envia a intenção de cobrança. Como a latência p99 é de 3 segundos, as chamadas de API são executadas de forma assíncrona com polling do lado do cliente no status do pedido em vez de bloqueio síncrono de thread HTTP. Tempo Limite e Resultados Incertos: Se a chamada atingir o tempo limite ou retornar um erro de rede ambíguo, o Serviço de Pedidos não falha o pedido imediatamente. Em vez disso, ele coloca o pedido em 'VERIFICANDO_PAGAMENTO' e inicia um worker de fallback que consulta o endpoint GET /charges/{idempotency_key} do provedor com backoff exponencial (por exemplo, em 2s, 5s, 10s). Buffer de Extensão de Retenção: Se um pedido entrar em 'VERIFICANDO_PAGAMENTO' dentro de 60 segundos antes da expiração da retenção de 8 minutos, o sistema concede uma extensão automática de segurança de 2 minutos na retenção do Redis para evitar a liberação de assentos enquanto uma cobrança é liquidada. Ingestão de Webhook: Webhooks do gateway de pagamento são validados por assinatura HMAC e gravados diretamente em uma fila durável antes do processamento, garantindo atualizações de estado idempotentes. Worker de Reconciliação: Um trabalho de reconciliação horário compara os relatórios de liquidação do gateway de pagamento com os registros do banco de dados para capturar quaisquer cobranças órfãs ou ingressos não processados. 5. Confiabilidade, Failover e Durabilidade dos Dados: Disponibilidade (99,95%) e Zero Perda de Dados: (a) Camada de Banco de Dados: O Aurora PostgreSQL é executado em 3 Zonas de Disponibilidade com replicação síncrona de armazenamento automatizada e réplicas de leitura. Se o gravador primário falhar, o failover automatizado promove uma réplica em menos de 30 segundos. (b) Camada na Memória: O Redis opera em uma topologia de mestre-réplica clusterizada entre AZs. No raro evento de falha irrecuperável do Redis, o estado do assento é reconstruído em 15 segundos por um trabalho de aquecimento que executa uma varredura rápida de índice na tabela de assentos do Aurora. (c) Recuperação de Desastres Regional: A replicação de armazenamento entre regiões do Aurora mantém um RPO de menos de 1 segundo. A Região B está configurada em standby frio/quente. Se a Região A sofrer uma interrupção catastrófica do provedor de nuvem, o failover de DNS redirecionará o tráfego para a Região B, onde os serviços escalam automaticamente e retomam as operações. (d) Idempotência: Todas as APIs (hold, pay, release) impõem restrições exclusivas em nível de banco de dados e tokens de idempotência do Redis para evitar efeitos colaterais duplicados durante as retentativas. 6. Principais Compromissos de Arquitetura: (1) Bloqueio Lua do Redis na Memória vs. Bloqueio Puro de Linha de Banco de Dados (SELECT FOR UPDATE). Rejeitado: Bloqueios diretos de linha no PostgreSQL para 500.000 solicitações simultâneas causam contenção massiva de bloqueio, enfileiramento de transações e esgotamento de conexões. Escolhido: Scripts atômicos Lua do Redis para arbitragem inicial de retenção, persistindo no Postgres de forma assíncrona/sequencial. Compromisso: Sincronização de estado de dupla camada ligeiramente mais complexa em troca de latência de microssegundos e nenhuma saturação do banco de dados. (2) Fila Virtual na Borda vs. Escalabilidade Automática Massiva de Serviços de Backend. Rejeitado: Escalar dinamicamente pods Kubernetes e bancos de dados para lidar com 500.000 RPS brutos para um evento com apenas 60.000 assentos no total é proibitivo em termos de custo e limitado pela taxa de gravação do Aurora. Escolhido: Fila na borda com taxa de admissão controlada. Compromisso: Os usuários esperam na fila, mas a estabilidade do sistema, os custos operacionais e a experiência do usuário permanecem previsíveis e robustos. (3) Polling Delta em Cache da CDN vs. WebSockets Full Duplex para Mapa de Assentos ao Vivo. Rejeitado: Manter 500.000 conexões WebSocket persistentes bidirecionais impõe sobrecarga severa de conexão com estado nos servidores de aplicativos. Escolhido: Polling delta da CDN com cache curto (1 segundo). Compromisso: Latência de 1 segundo na visualização do status do assento para os usuários, o que é totalmente tolerável, dada a verificação de retenção Lua transacional ao clicar. 7. Principais Métricas Operacionais e Alertas: Métricas: (a) Comprimento da Fila na Borda e Taxa de Entrada. (b) Taxa de Criação de Retenção e Taxa de Abandono. (c) Utilização de Memória do Redis, CPU e latência de execução de script Lua (p95, p99). (d) Conexões Ativas do Banco de Dados, Latência de Gravação e Atraso de Replicação. (e) Latência do Gateway de Pagamento (p50, p99), Taxa de Erro (5xx/timeouts) e Atraso na Ingestão de Webhook. (f) Contador de Violação de Invariante: COUNT(DISTINCT order_id) WHERE seat_id = X AND status = 'SOLD' > 1 (estritamente 0). Alertas Críticos: (1) Violação de Invariante: Qualquer detecção de assento vendido em excesso (P0, página instantânea). (2) Pico de Tempo Limite de Pagamento: Taxa de tempo limite de pagamento > 5% em 1 minuto (P1). (3) Memória/CPU do Redis: CPU > 75% ou contagem de evicção > 0 (P1). (4) Atraso do Reaper de Retenção Expirada: Atraso na fila do reaper > 30 segundos (P2).