Teste de carga em onboarding: dimensionando para o pico de marketing

A campanha está aprovada e o comercial vai ao ar no intervalo do jogo de domingo. Enquanto o marketing comemora, alguém da engenharia pergunta baixinho: o cadastro aguenta? Na maioria das empresas essa pergunta chega tarde, e é respondida com um teste de carga na página inicial, justamente a parte do sistema que menos importa nesse cenário.

O tráfego de onboarding não se comporta como média. Ele chega em pico agendado: uma inserção de televisão, um story de influenciador, uma promoção relâmpago com hora marcada. E o pico não se espalha pelo dia, ele se comprime em minutos. Quem dimensiona a verificação de identidade pela média diária descobre ao vivo que média e pico são coisas muito diferentes.

Este texto é para quem integra verificação de identidade no cadastro, seja KYC (Know Your Customer, conheça seu cliente), seja KYB (Know Your Business, conheça sua empresa), e tem uma campanha no calendário. A proposta: estimar a concorrência real com uma conta simples, testar o caminho que vai sofrer de verdade e planejar a degradação antes que ela aconteça sozinha.

Pico agendado não é média

Um produto que faz 12.000 cadastros num dia normal atende, na média, cerca de 0,14 cadastro por segundo. Qualquer servidor modesto dá conta. Agora coloque os mesmos 12.000 cadastros chegando nos 10 minutos seguintes a uma inserção em horário nobre: a taxa salta para 20 por segundo, cerca de 140 vezes a média. O sistema passa a operar num regime que nunca viu.

E o pico real costuma ser pior que a conta. A chegada não é uniforme nem dentro da janela: o primeiro minuto após o estímulo costuma concentrar a maior fatia. Além disso, sistema lento fabrica tráfego: o usuário que vê a tela travada recarrega a página e vira dois usuários do ponto de vista do servidor, exatamente no pior momento.

Por isso a pergunta de dimensionamento nunca é quantos cadastros por dia, e sim quantos chegam no pior minuto e quanto tempo cada um fica dentro do funil.

A conta da Lei de Little

A segunda metade da pergunta tem resposta formal desde 1961, quando John D. C. Little publicou a prova da fórmula que leva seu nome no artigo A Proof for the Queuing Formula L = lambda W, na revista Operations Research. A lei diz que o número médio de itens dentro de um sistema (L) é igual à taxa de chegada (lambda) vezes o tempo médio que cada item passa lá dentro (W). Em bom português: usuários simultâneos no funil igual a taxa de chegada vezes tempo de permanência.

Ela transforma o exemplo acima em número concreto. Um funil de verificação leva alguns minutos: criar a sessão, fotografar o documento, tirar a selfie, enviar tudo e esperar a decisão. Digamos 4 minutos, ou 240 segundos, de ponta a ponta.

Com 20 chegadas por segundo e 240 segundos de permanência, o funil carrega 20 x 240 = 4.800 usuários simultâneos. Não são 20 pessoas, são quase cinco mil: cinco mil sessões abertas, cinco mil conexões consultando status, milhares de uploads disputando banda. A média diária, pela mesma conta, sugeria 33 usuários simultâneos. É essa multiplicação silenciosa que derruba onboarding em dia de campanha.

A lei também aponta as duas únicas alavancas: reduzir a taxa de chegada (abrir a promoção em ondas, espalhar o estímulo) ou reduzir o tempo de permanência (funil mais curto, análise mais rápida). Todo o resto é consequência.

Quatro etapas, quatro custos

O segundo erro clássico é tratar o funil de verificação como uma coisa só, quando as etapas têm perfis de custo completamente diferentes.

• Criar a sessão é barato: uma escrita no banco e alguns tokens. Quase nunca é o gargalo, e é por isso que testar só essa etapa produz otimismo infundado.
• Upload de mídia pesa na banda. Selfie e documento somam vários megabytes por usuário; multiplicado por milhares de usuários simultâneos, o custo dominante vira tráfego de rede e armazenamento.
• Análise biométrica e documental é trabalho computacional pesado, e por isso costuma ser assíncrona: a requisição entra numa fila e é processada na vazão que os analisadores conseguem entregar. Na UNIFOKAL, por exemplo, o desenho é esse: a análise roda atrás de uma fila e a decisão sai de forma assíncrona, para que o pico de chegada não precise ser atendido em tempo real. Entender a diferença entre verificação síncrona e assíncrona muda o que você mede e o que promete ao usuário.
• Webhook de resultado inverte o papel: agora é o seu endpoint que precisa aguentar. As milhares de decisões do pico voltam como rajada de notificações, e se o receptor engasgar, o resultado existe mas não chega a quem interessa.

Dimensionar é medir cada etapa com a régua certa: conexões na primeira, banda na segunda, vazão de fila na terceira, capacidade do seu próprio servidor na quarta.

O que testar de verdade, e onde testar

Um teste de carga honesto percorre o caminho completo do usuário: cria a sessão, envia as mídias, espera a decisão e recebe o webhook. Ferramentas como k6 e JMeter permitem roteirizar esse fluxo com usuários virtuais que respeitam o ritmo humano; ninguém fotografa um documento em 50 milissegundos, e simular isso erraria o tempo de permanência da conta anterior.

Três cuidados no roteiro. Meça o tempo de funil completo por usuário virtual, não só a latência de cada endpoint isolado. Gere carga também contra o seu receptor de webhook, porque ele faz parte do pico. E suba a carga em degraus, segurando alguns minutos em cada patamar, para localizar o ponto de saturação depois.

E onde rodar? No ambiente de testes do fornecedor, nunca na produção dele sem combinar antes. O sandbox existe justamente para isso: exercitar o contrato completo sem custo por verificação e sem risco. Despejar carga na produção de um terceiro sem aviso é má etiqueta e má engenharia: limites de taxa existem, o teste será bloqueado no meio e, do lado de lá, ele é indistinguível de um ataque. O seu teste vira o incidente de outra equipe. Validação de capacidade em produção se combina por escrito, com janela, volume e contato de plantão.

Como ler o resultado e degradar sem cair

Descarte a média. Latência média esconde exatamente as pessoas que você quer enxergar. Leia percentis: o p95 marca o tempo que os 5% mais lentos excederam; o p99, o 1% com pior experiência. Num pico com 4.800 usuários simultâneos, o p99 representa uma dúzia de pessoas reais por minuto, geralmente as de rede pior, que são também as que mais recarregam a página.

Procure o ponto de saturação nos degraus do teste: o patamar em que a vazão para de crescer enquanto a latência explode. Antes dele, dobrar a carga dobra o atendimento; depois, dobrar a carga só alonga a fila. Esse número, e não a esperança, é a capacidade real do sistema.

Observe também a fila quando a chegada excede o serviço. Fila que cresce e drena depois do pico é o funcionamento esperado do desenho assíncrono; fila que cresce sem parar indica vazão de análise abaixo da taxa de chegada, e o tempo de decisão sobe para todos, o que, pela própria Lei de Little, incha ainda mais o sistema.

A meta do dia da campanha não é impedir qualquer lentidão, é degradação planejada em vez de queda: a fila cresce, a decisão demora um pouco mais, e a interface comunica a espera com honestidade, algo como "estamos analisando, avisaremos assim que terminar", enquanto o resultado chega de forma assíncrona. Usuário informado espera; usuário no escuro abandona e recarrega.

Antes da campanha, um checklist curto evita a maior parte dos sustos:

1. Avise o fornecedor do pico previsto, com data, horário e volume estimado.
2. Confira os limites de taxa contratados e o que acontece ao estourá-los.
3. Ensaie o dia no sandbox com pelo menos metade da carga esperada, incluindo o seu webhook.
4. Deixe o monitoramento da integração com alertas armados antes do primeiro comercial, não depois.
5. Prepare o texto de espera da interface para o cenário de fila longa.

O pico de marketing é um dos raros problemas de engenharia com data e hora marcadas. A diferença entre recorde de cadastros e noite de incidente é ter feito a conta, o teste e o ensaio enquanto errar ainda era barato.

Fontes citadas

• John D. C. Little, A Proof for the Queuing Formula L = lambda W, Operations Research, 1961.
• k6, ferramenta de teste de carga, citada por nome no texto.
• Apache JMeter, ferramenta de teste de carga, citada por nome no texto.