Quando o site cai na abertura de vendas, o público vai pro concorrente.

Downtime durante venda de ingressos custa receita perdida e público frustrado:

• Custo financeiro. Em pico de venda, cada minuto fora do ar é venda que não aconteceu.
• Abandono permanente. Quando o site cai na abertura de vendas, parte do público desiste. Num mercado onde o evento compete com outros eventos pela mesma janela de atenção, quem é empurrado pra "volte depois" já comprou ingresso de outro evento antes do site voltar.
• Dano reputacional. O público posta a tela de erro no Twitter/X. O site do FIFA World Cup 2026 enfrentou instabilidade durante vendas, com relatos de "ingressos alternando entre disponível e indisponível", e o público reclamou muito nas redes.
• Perda de dado. Se o site cai durante o pico e o checkout é interrompido, os carrinhos abandonados são dados de intenção perdidos. Quem tentou comprar e não conseguiu não aparece em nenhum relatório.

Os eventos com maior volume de tráfego no Brasil já resolveram isso com infraestrutura específica:

• Ingresso.com (Rock in Rio): Recebe mais de 1 milhão de visitantes durante a venda, com pico de 25 mil visitantes por minuto. Usa Queue-it como fila virtual: pré-fila antes da abertura, randomização no horário de abertura da venda. A fila virtual controla o fluxo e protege o backend de venda.
• Sympla: 38 milhões de visitas mensais, com capacidade pra picos de até 18 mil usuários por minuto em vendas de alta demanda. Usa Queue-it em modo Peak Protection 24/7.
• Ticket Tailor (referência internacional): Antes de implementar fila virtual (Queue-it), o banco de dados operava a 70% de utilização durante picos. Depois, caiu pra 10%. O sistema controla quantos usuários acessam o checkout por vez, absorvendo o restante na fila.

O denominador comum: nenhum deles tenta aguentar o pico inteiro. Todos usam fila virtual pra transformar um pico incontrolável numa fila controlada.

Porque ele depende de sistemas que não são dele.

No dia do evento, o app ou o site conversa com o CRM do organizador, com a ticketeira e com o controle de acesso.

Se um deles para de responder, o convidado vê "erro ao carregar o ingresso" enquanto o servidor do app segue verde nos gráficos.

Três cuidados resolvem a maior parte:

• Checar cada dependência em separado. Um monitor que só pergunta "o app tá no ar?" responde sim com o CRM fora. Ele precisa chamar o CRM, a ticketeira e o banco, um por um, a cada poucos minutos.
• Avisar quando o estado muda. Mensagem no canal da equipe quando algo cai e quando volta. Se o primeiro sinal de queda vem de alguém da produção dizendo "o app caiu", o monitoramento falhou.
• Deixar simples o que roda antes de cada requisição. Uma proteção com cota mensal, como um limitador de requisições, derruba todas as rotas no dia em que a cota acaba.

Evento de 5 mil ingressos, venda abre às 10h: O pico dura 15-30 minutos. CDN + cache de página estática resolve 90% da carga.

Se o checkout é numa plataforma externa (Sympla, Ingresse), o risco está no link entre o site e a plataforma. Monitore o redirecionamento.

Evento de 50 mil ingressos, alta demanda: Fila virtual é obrigatória. Sem ela, 25 mil visitantes por minuto colapsam qualquer backend de checkout.

Ingresso.com comprovou: controlando o fluxo de entrada com fila virtual (Queue-it), o backend aguentou a venda do Rock in Rio.

Dia do evento, site com programação ao vivo: O pico acontece quando o público já está no evento e acessa o site pelo celular (programação, mapa, informações).

4G sobrecarregado no venue + site sem cache = timeout. Geração estática (site pré-renderizado, sem banco) aguenta qualquer volume.

leia também: Seu fornecedor falhou. E agora? · Tecnologia pra primeira edição · Maturidade digital para eventos