Até certa escala, qualquer esquema funciona: um contorno, um fornecedor, uma planilha no bloco de notas no lugar de um banco de dados. A passagem de uma dezena de operações para centenas não faz essas soluções escalarem de forma linear — elas não ficam lentas aos poucos, elas quebram num ponto específico, e geralmente de surpresa. Vamos analisar quatro gargalos da infraestrutura e a ordem para resolvê-los.
Endereço de saída compartilhado: como ele liga o que deveria estar separado
A economia na infraestrutura costuma começar com uma única decisão: vários contornos independentes saem para a rede pelo mesmo endereço. Enquanto são dois ou três contornos, o risco é pequeno. Quando são vinte, a plataforma ganha um sinal de ligação pronto: contas diferentes, horários de atividade diferentes, mas o mesmo ASN e o mesmo IP. O banimento de um contorno por esse sinal aumenta a desconfiança sobre os demais, mesmo que formalmente eles não violem nada. O que a plataforma enxerga no endereço e por que isso funciona como uma impressão digital está no artigo sobre o que é ASN e por que ele é importante.
O sinal de que o limite está próximo são picos sincronizados de verificação em contornos que formalmente não têm relação: várias contas recebem ao mesmo tempo um captcha ou um pedido para confirmar o telefone sem motivo aparente — a causa provável é o endereço compartilhado, e não coincidência.
Controle manual de números e endereços: onde a planilha quebra
Uma planilha no bloco de notas ou num documento na nuvem funciona muito bem enquanto uma única pessoa cuida dela e há menos de cinquenta registros. Depois disso, as divergências começam a se acumular: o número está marcado como livre, embora ainda esteja vinculado a um contorno ativo; o endereço consta como ativo, embora tenha expirado há três dias; dois contornos recebem por engano o mesmo recurso, porque o registro foi atualizado não no momento da entrega, mas «depois, quando houver tempo».
O sinal do limite é a pergunta «de quem é isso?» aparecer várias vezes por semana. O segundo sinal é a divergência entre a planilha e o que realmente está ativo no fornecedor. A solução não é disciplina, e sim mover o momento do registro para o ponto de entrega do recurso: o número e o endereço entram no controle no momento da entrega, e não quando alguém se lembra de anotá-los.
Teto do fornecedor: limites que não aparecem de imediato
Todo fornecedor de números e endereços tem limites práticos, imperceptíveis em volume pequeno: velocidade de processamento de solicitações paralelas, o passo de recarga do saldo, o limite de sessões simultâneas pela área do cliente. Com uma dezena de operações por dia, esses limites não são atingidos. Com uma centena, os pedidos começam a falhar nos horários de pico, embora o recurso esteja formalmente disponível.
O sinal é que erros e timeouts se concentram em horários específicos, em vez de se distribuírem de forma uniforme. Esse é o sintoma de que se bateu no limite de operações paralelas pela interface web, e não de falta de números ou endereços: a área do cliente fisicamente não foi feita para dezenas de solicitações por minuto, ela foi projetada para uma pessoa clicando com o mouse.
Consumo de tráfego não linear: por que as repetições custam mais que o crescimento
O tráfego em tarefas automatizadas cresce mais rápido que o número de operações, e a causa geralmente não são as operações em si, mas as repetições. Uma sessão interrompida por causa de um endereço instável obriga a automação a recomeçar — com novo carregamento de imagens, fontes e rastreadores, baixados em vão na primeira vez. Cem verificações de fichas de produtos consomem cerca de 0,3–0,5 GB; mil, já 3–5 GB, desde que as sessões não caiam. Num canal instável, o consumo real pode ficar uma vez e meia a duas vezes acima do calculado, só por causa das repetições.
O sinal do limite é a conta de tráfego crescer mais rápido que o número de tarefas concluídas: não é que haja mais operações, é que parte delas é executada duas ou três vezes. A solução é desativar o carregamento de mídia e de rastreadores onde não é preciso uma cópia visual da página, e impor um limite rígido de repetições no nível do script, em vez de um retry infinito.
O que resolver primeiro e quando migrar do modo manual para a API
A ordem de correção não é determinada pelo que quebrou primeiro, e sim pelo que é mais barato de resolver e mais caro de deixar sem resolver. Em primeiro lugar, o isolamento dos endereços: separar os contornos em IPs diferentes sai barato, e o risco de banimento em cascata é o mais caro dos quatro cenários. Em segundo, uma fonte única de verdade sobre números e endereços: sem ela, escalar só aumenta o número de recursos sem dono. Em terceiro, a higiene do tráfego: desativar carregamentos desnecessários e limitar as repetições. Em quarto, geralmente o último em termos de tempo, a migração do modo manual para a API.
O momento da migração é definido não pelo calendário, mas pela frequência com que se bate no teto: se os pedidos pela área do cliente falham regularmente nos horários de pico, ou se a digitação manual leva mais tempo do que a própria operação, o trabalho manual sai mais caro que a integração. A API elimina o limite de solicitações paralelas e tira a pessoa da cadeia de entrega do recurso — a diferença entre «uma pessoa clica» e «o servidor responde» se torna decisiva com uma centena de operações por dia. O lado prático da migração está na configuração da rotação de IP por API.
Perguntas frequentes
Quantos contornos posso manter num mesmo endereço antes de isso virar um problema?
Não existe um número universal — depende do quanto a plataforma confere o ASN e o histórico do endereço. A regra é simples: se os contornos precisam continuar independentes caso um deles seja banido, o endereço não deve ser compartilhado em nenhuma escala.
Dá para passar sem um controle único de números e endereços quando o volume cresce?
Até algumas dezenas de registros ativos, sim — a planilha dá conta. Depois disso, as divergências entre o controle e a realidade crescem mais rápido do que uma única pessoa consegue registrar, e o custo do erro — a entrega repetida de um recurso ocupado — é maior que o custo de um controle adequado.
Vale migrar para a API sem esperar bater nos limites da área do cliente?
Se o crescimento é previsível e a conta já chega a centenas de operações por mês, sim: é mais barato fazer a migração com antecedência do que no momento em que o modo manual já não dá conta e cada hora de parada custa dinheiro.
Se a infraestrutura está apoiada num único contorno de forma deliberada, e não temporária, o conjunto mínimo para esse modo está no artigo sobre a stack barata para especialista solo. Ativações avulsas e a migração para a API estão na seção de aluguel e ativação de números.