Quando a IA acelera tudo, o maior risco é achar que “já terminou”
Com IA, um app multiplayer pode sair da ideia para algo funcional em uma velocidade absurda. A sala abre, pessoas entram, publicam e votam. O cérebro anuncia:
Pronto.
O servidor responde:
Você testou com uma pessoa.
As perguntas importantes vêm depois: e 100 pessoas ao mesmo tempo? E se o banco salvar, mas a resposta de sucesso sumir? E se o último voto chegar junto do prazo? E se um aviso de pagamento chegar duas vezes? E se todo mundo reconectar no mesmo segundo após uma falha?
Uma revisão de código de um pequeno app multiplayer virou 324 casos de teste. Isso não quer dizer que havia 324 bugs. Todos ainda estavam sem execução. Era um plano, não um certificado de aprovação.
1. DDoS não é a única forma de um app travar
A Cloudflare oferece mitigação automática de DDoS em todos os planos, mas também recomenda controles como rate limiting, porque ataques grandes ainda podem afetar a aplicação.[1]
Em projeto pequeno, tráfego legítimo pode ser o primeiro problema.
Com consulta de estado a cada 3 segundos:
| Dispositivos simultâneos | Consultas por hora |
|---|---|
| 10 | 12.000 |
| 30 | 36.000 |
| 100 | 120.000 |
| 1.000 | 1.200.000 |
Não é previsão real de capacidade. Backoff e cache diminuem; posts, imagens, caixa de entrada, várias abas e tarefas agendadas aumentam.
Em 5 de outubro de 2026, Workers Free lista 100.000 requests/dia. D1 Free lista 5 milhões de linhas lidas/dia, 100.000 linhas escritas/dia, 500 MB por banco e 50 consultas por invocação do Worker.[2][3] Um banco D1 processa consultas uma por vez; concorrência excessiva cria fila e pode terminar em erro de sobrecarga.[3]
Ou seja: não são só “um milhão de atacantes”.
Cem usuários legítimos se divertindo ao mesmo tempo também podem ser um teste de carga.
2. Por que a lista chegou a 324
Foram 16 áreas: entrada e abuso, capacidade, concorrência e recuperação, tarefas agendadas, salas e permissões, imagens, texto, votação, prazos, liberação de resultados, salas públicas, conexões persistentes, dispositivos e reconexão, integrações, pagamentos e implantação/monitoramento.
A saída é priorizar.
3. Os 23 pontos que eu testaria primeiro
- Requisições rejeitadas ainda fazem trabalho caro no banco?
- O contador interno mede todas as rotas caras?
- O rate limit sobrevive a reinícios e múltiplas instâncias?
- “Nada mudou” ainda lê muito banco?
- Uma única vaga pode abrir conexões persistentes ilimitadas?
- HTTP e conexão persistente aplicam os mesmos limites?
- Um desligamento de emergência afeta clientes já conectados?
- Atraso do agendador deixa entrar ação depois do prazo?
- Uma gravação secundária pode falhar e a sala avançar mesmo assim?
- Reparos repetidos podem duplicar estatísticas?
- A reserva de início pode ser consumida antes da partida existir?
- Um retry pode transformar uma resposta em duas?
- Variações visuais de nome burlam unicidade?
- Duas pessoas podem pegar a última vaga?
- O agendador pode acumular mais trabalho do que consegue processar?
- O tamanho total do banco e índices é medido?
- Outra pessoa consegue assumir a identidade de um aparelho perdido?
- Tipo, dimensões, metadados e localização de imagens são tratados com segurança?
- Histórico longo torna cada tela cada vez mais cara?
- Reconexão sincronizada cria uma segunda queda?
- Pagamentos duplicados, atrasados, falhos, cancelados e restaurados foram testados?
- Teste local aprovado está sendo confundido com produção aprovada?
- Se o banco cair, a monitoria cai junto?
4. Bugs gostam de combinações
Cenário de alto valor:
100 votam juntos → 20 atualizam → 10 perdem conexão → algumas gravações funcionam mas a resposta some → retry.
Aí se observa voto duplicado, voto atrasado, tela voltando para estado antigo e operação executada duas vezes.
A OWASP também trata sessões concorrentes, entradas anormais e tratamento de erro como áreas separadas de teste.[4]
5. Salvar e receber o “OK” são eventos diferentes
O servidor pode ter gravado. A resposta pode ter sumido na rede.
O usuário vê falha e toca de novo.
Sem identificador de operação ou deduplicação, nasce uma segunda resposta, sala, votação, notificação ou cobrança.
Retry precisa ser projetado.
6. Teste de carga deve subir em etapas
Em ambiente controlado: 10 → 30 → 100 clientes.
Depois mude o formato: uma sala lotada, muitas salas, entradas simultâneas, votos finais simultâneos, reconexão em massa, tarefas agendadas e falhas simuladas de armazenamento.
Não envie tráfego massivo para sistemas de terceiros ou ambientes sem autorização. Defina orçamento e condição de parada antes.
7. “Não caiu” não é aprovação
Uma meta inicial pode ser 95% das requisições comuns abaixo de 1 segundo, 99% abaixo de 3 segundos e 5xx inesperado abaixo de 0,1%.
Mas algumas coisas têm tolerância zero:
- dados de outra pessoa expostos;
- ação sem permissão;
- pontuação duplicada;
- dado confirmado perdido;
- cobrança dupla.
8. Plano 9/10, evidência executada 0/10
Uma lista de 324 testes e 23 riscos prioritários pode ser ótima.
Antes de rodar, porém, a evidência é zero.
Isso não é ruim. Você saiu de “não sei o que testar” para “sei onde tentar quebrar”.
9. Depois quem bate no limite pode ser a IA
Um dia inteiro fazendo IA ler repositório grande, implementar, corrigir e revisar pode consumir a cota antes do servidor.
Em 5 de outubro de 2026, Claude Max 20x custa US$ 200/mês na web. O “20x” é capacidade por sessão em relação ao Pro. A sessão reinicia a cada cinco horas, mas existe também limite semanal compartilhado por todos os modelos.[5]
20x não é infinito.
O consumo exato muda com modelo, contexto e tarefa; Settings > Usage é a referência prática.
10. “Fable é caro” também aparece nos números
No Max, Fable 5 e 5.1 fazem parte do plano, mas Fable pode usar até 50% do limite semanal e, segundo a Anthropic, consome esse limite mais rápido que outros modelos.[6]
| Modelo | Entrada / 1M tokens | Saída / 1M tokens |
|---|---|---|
| Sonnet 5.5 | $2 | $10 |
| Opus 5.5 | $4 | $20 |
| Fable 5.1 | $10 | $50 |
Fable 5.1 custa 2,5 vezes o preço de Opus 5.5 em entrada e saída. Cache mais barato reduziu o custo em relação ao Fable 5, mas o valor absoluto continua alto.[6][7][8]
Preço de API não vira diretamente minutos da cota Max, mas a conclusão continua: modelo pesado por muitas horas custa caro de algum jeito.
11. Não use guindaste para todo parafuso
Sonnet 5.5: correções rotineiras, bugs conhecidos, trabalho repetitivo, implementação bem delimitada.
Opus 5.5: causa desconhecida, arquitetura, revisão em muitos arquivos, decisões críticas.
Fable 5.1: tarefas realmente difíceis em que a capacidade extra justifica maior custo ou consumo de limite.
Não é ranking. É custo por tarefa.
12. IA move o gargalo
Antes: ideia → semanas de código → testes.
Agora: ideia → implementação rápida → testes, operação, limite do servidor e limite de IA chegam juntos.
“Fiz o app em um dia” pode ser verdade.
Mais preciso:
“Em um dia cheguei ao ponto em que já posso tentar quebrá-lo de verdade.”
A preparação para produção começa aí.
- Cloudflare DDoS developers.cloudflare.com
- Cloudflare Workers developers.cloudflare.com
- Cloudflare D1 developers.cloudflare.com
- OWASP WSTG wstg.owasp.org
- Anthropic Max support.claude.com
- Anthropic Fable support.claude.com
- Opus 5.5 anthropic.com
- Sonnet 5.5 anthropic.com
