Quando o site cai na abertura de vendas, o público vai pro concorrente.
O Ingresso.com recebeu 25 mil visitantes por minuto na venda do Rock in Rio, a Sympla atinge 18 mil usuários por minuto em picos e o site do FIFA World Cup 2026 teve instabilidade no lançamento de ingressos. O pico é certeza; o que fica em aberto é se a arquitetura foi dimensionada pra ele.
por nox. · 8 min de leitura · atualizado em março 2025
Sites de eventos têm um padrão de tráfego que nenhum e-commerce tem: semanas de visitas baixas, seguidas de picos extremos concentrados em minutos (abertura de vendas, anúncio de lineup, evento-dia). A maioria dos sites é dimensionada pro tráfego normal. Quando o pico chega, o site cai, e no ciclo de venda de um evento não existe a opção de pedir pro público voltar depois.
Resumo rápido. Sites de evento têm picos extremos concentrados em minutos. Abertura de vendas, anúncio de lineup, evento-dia. As causas de queda: hospedagem compartilhada, banco de dados sobrecarregado, falta de CDN, falta de cache, bots competindo com público real, ausência de fila virtual. Cada minuto fora do ar custa receita perdida e dano reputacional. As camadas de proteção: CDN, cache com geração estática, fila virtual (Queue-it ou Cloudflare Waiting Room), auto-scaling, proteção contra bots, teste de carga a 2x o pico esperado. Ingresso.com, Sympla e Ticket Tailor usam fila virtual pra transformar pico em fluxo controlado.
Quais são as causas técnicas de queda e como identificar cada uma?
| Causa | O que acontece | Sinal visível | Solução |
|---|---|---|---|
| Hospedagem compartilhada | CPU e RAM divididos com outros sites. Um pico no seu site derruba o servidor inteiro. | Site lento, erro 503, timeout. | Migrar pra VPS, dedicado, ou plataforma com auto-scaling (Vercel, AWS). |
| Banco de dados sobrecarregado | Cada visita gera 30-100 queries no banco. Milhares simultâneas esgotam conexões. | Site carrega parcialmente, checkout trava, erro de timeout no banco. | Connection pooling, indexação, cache de queries frequentes. |
| Sem CDN | Cada visitante busca imagens, CSS, JS direto do servidor de origem. | Site lento globalmente, tempo de carregamento >5s. | CDN (Cloudflare, AWS CloudFront) serve conteúdo estático do edge. |
| Sem cache | Páginas estáticas (programação, mapa, FAQ) são geradas dinamicamente a cada visita. | Servidor processa o que poderia servir pronto. | Cache de página inteira, geração estática (SSG), ISR. |
| Bots + tráfego orgânico | Scalpers e bots competem com público real, multiplicando a carga. | Tráfego 3-5x maior que o esperado. Padrões de acesso não-humanos. | Rate limiting, CAPTCHA, detecção de bots, fila virtual. |
| Sem fila virtual | Todos os visitantes chegam ao checkout simultaneamente. Servidor colapsa. | Página de checkout inacessível, carrinho expira, vendas perdidas. | Virtual queue (Queue-it, Cloudflare Waiting Room) controla o fluxo. |
Seu evento vai abrir vendas e o site não foi testado pra carga? Manda um alô antes, não depois.
Quanto custa cada minuto fora do ar.
Downtime durante venda de ingressos custa receita perdida e público frustrado:
- Custo financeiro. Em pico de venda, cada minuto de indisponibilidade é receita não realizada.
- 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", gerando frustração massiva 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.
Como os grandes eventos lidam com picos.
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 às 17h45, randomização às 19h (horário de abertura). O sistema controla o fluxo através de fila virtual, gerenciando a carga no backend de venda.
- Sympla: 50 mil usuários únicos por dia, com picos de 5 mil a 18 mil usuários por minuto durante eventos de alta demanda. Usa Queue-it em modo Peak Protection 24/7. 38 milhões de visitas mensais.
- Ticket Tailor (referência internacional): Antes de implementar Cloudflare Waiting Room, 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.
Camadas de proteção contra pico de tráfego.
CDN (Content Delivery Network)
Serve imagens, CSS, JS do servidor mais próximo do visitante. Reduz carga no servidor de origem em 50%+. Cloudflare, AWS CloudFront, Vercel Edge.
Cache e geração estática
Páginas que não mudam (programação, FAQ, mapa) servidas prontas, sem acessar banco. Reduz queries em 90%+ durante pico.
Fila virtual (virtual queue)
Controla quantos visitantes acessam o checkout por vez. Queue-it (usado por Ingresso.com, Sympla) e Cloudflare Waiting Room são os padrões.
Auto-scaling
Servidor adiciona instâncias automaticamente quando a carga sobe. AWS, Google Cloud, Vercel fazem isso nativamente. Hospedagem fixa, não.
Proteção contra bots
Rate limiting, CAPTCHA, e detecção de bots impedem que scalpers multipliquem a carga. Cloudflare Bot Management, reCAPTCHA.
Teste de carga pré-evento
Simular o pico esperado antes da abertura de vendas. JMeter, k6, LoadImpact. Testar a 2x o pico esperado pra ter margem.
Sinais de que o site do seu evento vai cair no próximo pico.
O site está em hospedagem compartilhada
Se paga menos de R$50/mês de hosting e divide servidor com outros sites, qualquer pico de 1.000 visitantes simultâneos é risco.
Nunca foi feito teste de carga
Se ninguém simulou o volume esperado de abertura de vendas, o evento é o próprio teste de carga. No dia, com público real.
O site leva mais de 3 segundos pra carregar no normal
Se no dia comum já é lento, no pico vai travar. Performance no estado normal é o baseline. No pico, tudo piora.
Não tem CDN configurada
Se todo conteúdo vem do servidor de origem (verificável pelo header do response), cada visitante gera carga máxima.
A última venda de ingressos "deu problema"
Se o site já caiu ou ficou lento na última venda e "resolvemos aumentando o plano," o problema é arquitetural, não de capacidade pontual. O próximo pico vai ser maior.
A nox. constrói os sites de eventos como SPFW e SP Open, que precisam aguentar pico em abertura de vendas, programação ao vivo e dia de evento. CDN, cache, geração estática e monitoramento em tempo real. Os padrões abaixo vêm de operar essa camada nos picos reais.
Na prática.
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 pra 10 mil/min via Queue-it, o backend aguentou a venda do Rock in Rio.
Evento-dia, 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
Perguntas frequentes.
CDN resolve sozinha?
CDN resolve a carga de conteúdo estático (imagens, CSS, JS). Se o checkout, credenciamento, ou busca de programação dependem de banco de dados, o gargalo está no backend, não no frontend. CDN é a primeira camada, não a única.
Fila virtual não frustra o público?
Menos do que site fora do ar. Fila com estimativa de tempo ("sua posição: 4.523, tempo estimado: 8 minutos") é experiência controlável. Página de erro 503 é experiência incontrolável. O Ingresso.com comprovou: fila + randomização reduziu frustração comparado a "site caiu, tente depois."
Quanto custa proteger o site contra pico?
CDN (Cloudflare): plano gratuito já ajuda, plano Pro a partir de ~R$100/mês. Queue-it: pricing por volume. Cloudflare Waiting Room: incluso no plano Business (~R$1.000/mês). Auto-scaling (Vercel, AWS): pay-per-use. O custo é frações do que se perde com 30 minutos de downtime durante venda.
Meu site é WordPress. Posso proteger contra pico?
Pode, mas WordPress é especialmente vulnerável: cada pageview pode gerar 30-100 queries no banco. Cloudflare CDN + cache de página inteira (WP Rocket, W3 Total Cache) + hospedagem VPS (não compartilhada) cobrem 80% do problema. Pra pico de venda, adicione fila virtual.
E se o pico for causado por bots/scalpers?
Bots multiplicam o tráfego real por 3-5x. Rate limiting (máximo de requests por IP), CAPTCHA no checkout, e detecção de bots (Cloudflare Bot Management) filtram tráfego não-humano antes de chegar ao servidor. O FIFA World Cup 2026 enfrentou isso: bots e tentativas de acesso não autorizado compondo a instabilidade.
Teste de carga pode derrubar meu site?
Se feito no site de produção em horário de tráfego, sim. Teste em ambiente staging com a mesma configuração do production. Ferramentas como k6 e JMeter permitem simular volume gradual. Teste a 2x o pico esperado. Se aguentar 2x, tem margem.
Posso resolver com "mais servidor"?
Aumentar servidor (vertical scaling) ajuda até um ponto. Mas sem CDN, cache, e fila virtual, o gargalo se move do servidor pra o banco de dados, do banco pra o checkout, do checkout pra a infraestrutura de pagamento. A solução é arquitetural, não de capacidade bruta.
seu site caiu na abertura de venda ou na semana do evento?
conta o que aconteceu e a gente mostra a infra que aguenta o pico, e quem fica de plantão no dia. sem compromisso.