Atualização editorial em : fontes e exemplos revistos; a data da publicação original foi preservada.
Uma aplicação que aceita mais requisições não necessariamente conclui mais operações úteis. Para decidir quando aumentar capacidade, é preciso separar demanda, trabalho concluído e espera por dependências. O caso apresentado por Durai Arasan ajuda a formular essas perguntas; não fornece uma configuração universal de escalabilidade.
O que o caso publicado descreve
Em Scaling Cloud and Distributed Applications, publicado em 04/12/2025, Durai Arasan relata aprendizados da migração do Chase.com para a nuvem. O autor discute picos de tráfego, tempo de inicialização da capacidade adicional e sinais de escala que podem ser confundidos com lentidão de uma dependência. A preparação para dez vezes a carga pertence ao contexto descrito por ele. Não é um requisito recomendado para qualquer aplicação, nem uma experiência profissional de Anderson Damasio.
Um experimento proposto para separar os gargalos
Considere, como hipótese, uma API de pedidos que consulta estoque e grava uma confirmação. Antes de testar, defina quais respostas contam como pedido concluído: um HTTP 200 de recebimento não basta se a confirmação ocorre depois. Use identificadores de pedido para distinguir uma repetição de uma operação nova.
- Referência: mantenha a carga constante e registre pedidos concluídos por segundo, p95 de duração, erros e profundidade da fila. Registre também tamanho das instâncias, quantidade de réplicas e versão do código.
- Dependência lenta: introduza atraso apenas no estoque, em ambiente isolado. Compare a taxa de pedidos concluídos com a quantidade de requisições ainda em andamento. Aumentar réplicas sem elevar as conclusões é evidência contra a hipótese de falta de capacidade da API, não prova definitiva da causa.
- Capacidade adicional: repita o mesmo perfil de carga e altere somente o número de réplicas. Meça o intervalo entre solicitar uma réplica e ela atender corretamente. Não use apenas o instante em que o processo inicia.
- Retorno à carga inicial: interrompa a injeção de atraso e observe a drenagem da fila. Verifique pedidos duplicados, recusados e ainda pendentes antes de declarar recuperação.
A ficha do ensaio deve registrar a hipótese, a alteração realizada, o limite de interrupção e o resultado esperado antes da execução. Por exemplo: “Se o estoque limitar a vazão, mais réplicas da API não aumentarão proporcionalmente os pedidos confirmados”. O resultado pode contrariar essa previsão; nesse caso, preserve os dados e revise a hipótese.
Escolha limites de duração, custo e erro de acordo com o serviço. Ao atingir um deles, pare o gerador de carga e restaure a configuração anterior. Não faça esse ensaio em produção sem autorização e controles específicos.
O que esta leitura não demonstra
O experimento acima é uma proposta didática, não um teste executado neste site. Nenhum ganho de desempenho ou disponibilidade de 100% foi demonstrado. O relato da fonte pertence à organização descrita por Durai Arasan; a análise não transfere seus resultados para outras arquiteturas.