Drop de merch que não cai: infra pra aguentar tweet viral
Por que builder genérico cai em pico de tráfego e o que precisa ter na infra de página de drop pra aguentar 30k pessoas em 15 minutos. Checklist prático.
Você tweetou: "drop tá no ar". Em 15 minutos, 30 mil pessoas clicaram no link. Em 18 minutos, a página estava fora. Em 25 minutos, você tava no DM do suporte do builder explicando o que aconteceu, enquanto a audiência ironizava na thread.
Drops virais são quase sempre uma combinação de timing + audiência aquecida + um pouco de sorte. Mas a infraestrutura que aguenta o pico não é sorte — é decisão prévia. Esse artigo é sobre as decisões que separam um drop que vende tudo de um drop que vira meme.
Por que builder genérico cai
Antes de tudo: você não fez nada de errado escolhendo plataforma. Wix, Webflow, Shopify, Hotpage de infoprodutor — todos funcionam ótimo pra fluxo normal. O problema é específico do pico viral.
Três coisas tendem a quebrar simultaneamente quando um tweet decola:
1. Servidor de origem satura. Builder hospeda muitas lojas no mesmo cluster. Quando a sua dispara, você compete com a infra dos vizinhos. Resposta da plataforma: "estamos investigando" — mas o drop não espera.
2. Provedor de pagamento começa a recusar. Stripe, PayPal, Hotmart, Pix gateway — todos têm rate limits. Um drop de 30k pessoas em 5 minutos triggera regras antifraude e o gateway começa a recusar transação válida. Você não vê — você só vê CTR alto e conversão baixa.
3. CDN do builder não tem cache agressivo. A página tem 2-3 chamadas dinâmicas (preço atualizado, estoque atual, banner regional) que precisam ir até o servidor a cada visita. Em 1.000 visitas simultâneas, fila se forma e tudo fica lento.
A combinação dos três é o que produz o "tá fora?" no DM.
Os 3 fatores que matam página em pico
Por ordem de impacto:
1. Cache. Se cada visita tem que ir até o servidor pra renderizar, você tá vulnerável. Página de drop deveria ser quase 100% estática — pré-renderizada e servida via CDN. Tudo que precisa ser dinâmico (estoque, preço) vai por chamada separada, em camada que pode escalar independente.
2. Provedor de pagamento. Você precisa entender o limite de TPS (transações por segundo) do seu gateway. Stripe permite ~100 TPS por conta padrão; Pix tem limite por banco. Em drops grandes, você precisa pedir aumento de limite com antecedência ou enfileirar o checkout.
3. DNS e propagação. Se você comprou domínio na semana passada e configurou DNS na véspera, prepare-se: pode demorar até 48h pra propagar globalmente. No dia do drop, parte da audiência vai resolver pra IP antigo e nada vai funcionar pra eles. Resolver com pelo menos 1 semana de antecedência.
O que muda quando tem 10k pessoas simultâneas
Pra dar dimensão concreta, alguns números reais:
- Em 1k visitas/min, qualquer infra decente aguenta. Não pense nisso.
- Em 5k visitas/min, builder genérico começa a degradar. Latência sobe de 200ms pra 2s. Conversão cai porque mobile dá timeout.
- Em 10k visitas/min, builder genérico cai completamente. Você precisa de arquitetura pensada pra escala.
- Em 30k+ visitas/min, mesmo arquitetura pensada vai sofrer se você não configurou queue na camada de checkout.
A maioria dos creators superestima ou subestima esse número. Subestima quando o canal cresce muito rápido. Superestima quando confia em "anúncio pago tem CTR de 2%". Use seu histórico de engajamento de drops anteriores como baseline — multiplique por 3 se você usou anúncio pago, por 5 se influencer maior te citou, por 10 se viralizou organicamente.
Checklist de infra mínima
Pra page de drop que precisa aguentar pico, o mínimo absoluto:
1. Página estática servida via CDN. Vercel, Cloudflare Pages, Netlify — qualquer um deles aguenta pico viral porque a página em si tá em edge cache. CTR não toca seu servidor.
2. Chamadas dinâmicas separadas e com cache. Estoque/preço atual via API com cache de 10-30s (não real-time). Você perde precisão milimétrica em troca de não cair.
3. Fila no checkout. Se você tá usando Hotmart/Kiwify/Stripe, não precisa fazer nada — eles têm fila interna. Se tem checkout próprio, considere enfileirar (Cloudflare Queues, Redis Streams, ou serviços tipo Shopify Hydrogen).
4. Monitoring em tempo real. Você precisa ver durante o drop: latência, taxa de erro, taxa de conversão, requests por segundo. Datadog, Vercel Analytics, ou até Cloudflare Analytics free tier resolvem. Sem isso você fica adivinhando.
5. Plano de degradação graciosa. Se algo cair, o que você desliga primeiro? Banner regional? Recomendação de produto? Comentários? Defina antes — durante o drop você não tem cabeça pra decidir.
6. Fallback de domínio. Tenha um subdomínio backup (drop.seunome.com) apontando pra infraestrutura diferente. Se o domínio principal cair, você tweeta o backup em 30 segundos.
7. Tráfego de teste prévio. Rode um simulador (k6, Loader.io) gerando 5x o tráfego que você espera, 1 semana antes. Se a página aguentar, você dorme tranquilo. Se não, você tem tempo de corrigir.
Hospedagem: Vercel vs Netlify vs Cloudflare
Real talk:
- Vercel — melhor DX, integração nativa com Next.js, edge functions globais. Caro em pico (cobrança por function invocation). Recomendado se sua stack é Next + você quer simplicidade.
- Cloudflare Pages + Workers — mais barato em pico, edge functions globais com modelo de cobrança mais previsível. Curva de aprendizado maior. Recomendado se você espera tráfego muito alto recorrente.
- Netlify — meio do caminho. Bom pra projeto estático puro. Function pricing menos amigável em pico.
Pra drop ocasional (1-2 por trimestre), Vercel é o caminho de menor fricção. Pra creator que faz drop toda semana, Cloudflare começa a fazer sentido financeiro.
Plano de mitigação se algo cair
Drop viral vai ter incidente. Não é "se", é "quando". O que separa drama de incidente:
- Página estática de "voltamos em 5 minutos" pronta pra fazer deploy em 30 segundos. Quase nenhum creator tem isso. Custa 1 hora de trabalho prévio, salva o lançamento.
- Comunicação preparada — tweet, story, mensagem no Discord pré-escritos. "Tô vendo aqui, volto em 10 minutos com update." Audiência perdoa erro, não perdoa silêncio.
- Plano B de checkout — link pra hotmart/kiwify/loja externa que você pode mandar manualmente se o checkout principal cair. Não é elegante, mas converte.
- Pessoa designada pra fazer triagem — não pode ser você sozinho monitorando tudo. Designe alguém do time pra responder DM e Twitter enquanto você decide o que tecnicamente fazer.
TL;DR
Página de drop precisa ser quase estática (pré-renderizada, servida via CDN), com chamadas dinâmicas cacheadas e checkout em plataforma robusta. Builder genérico aguenta tráfego normal mas degrada em pico viral. Custos relevantes não são só hosting — são o de não ter a infra: drop que cai vira meme, audiência queima, marca esquece.
Se você tem drop importante chegando e quer garantir que a infra aguenta, conta a gente. Avaliamos em 24h e respondemos com plano específico. O ideal é avisar pelo menos 2 semanas antes — não 2 dias.
Você também pode gostar
Continue explorando nosso conteúdo sobre landing pages e desenvolvimento web.
Linktree não basta: quando o creator precisa de site próprio
Os 5 sinais de que sua audiência ficou maior que Linktree, o que site próprio destrava e o caminho mínimo pra migrar sem virar projeto eterno.
Quando seu jogo precisa de dashboard de Live Ops (e quando ainda não)
Os sinais de que seu jogo está pedindo dashboard de Live Ops, o mínimo viável de uma v1 e quando faz sentido construir interno vs terceirizar a primeira versão.