Escalabilidade é a capacidade de ajustar os recursos de um sistema à carga de trabalho e aos objetivos definidos para ele. Isso não significa suportar qualquer volume sem limites nem adicionar servidores sempre que o negócio cresce. Significa entender a demanda relevante, definir o desempenho necessário e saber onde ampliar ou reorganizar a capacidade quando as medições apontarem essa necessidade.
A carga não se resume ao número de visitantes
O volume de acessos importa, mas o trabalho que cada acesso provoca também. Uma página de leitura pode exigir pouco processamento; uma operação que grava dados, consulta várias tabelas ou chama serviços externos pode consumir bem mais recursos. Importações, relatórios e outras tarefas em segundo plano formam cargas diferentes das solicitações interativas.
A demanda também varia no tempo. Pode ser estável, crescer gradualmente, acompanhar uma época do ano ou surgir em picos curtos. Por isso, conte operações e concorrência, observe o tamanho dos dados e separe leituras, gravações e tarefas demoradas. Uma loja hipotética, por exemplo, pode receber mais consultas durante uma campanha e, ao mesmo tempo, concentrar gravações no checkout.
Defina o que precisa continuar funcionando bem sob essa carga: quanto tempo uma operação pode levar, qual volume deve ser processado e até quando uma tarefa pode ficar pendente. Esses objetivos de desempenho, junto com uma estimativa de demanda, dão contexto para decidir se a capacidade atual é suficiente.
Descubra o gargalo antes de ampliar
Meça o caminho completo da operação e seus componentes. Tempo de resposta, volume processado, erros, uso de CPU e memória ajudam, mas também podem importar o tempo das consultas, conexões disponíveis no banco, armazenamento, tráfego de rede, tamanho de filas e respostas de serviços externos. A orientação de capacidade do Azure Well-Architected Framework recomenda escolher métricas que representem a carga real, como profundidade da fila ou consultas ao banco, além de CPU e memória.
Se o servidor da aplicação estiver sobrecarregado, mais instâncias podem ajudar. Se o limite estiver no banco de dados, na cota de uma API ou em outro fornecedor, multiplicar servidores pode não melhorar a operação e ainda aumentar a pressão sobre essa dependência. Em um exemplo hipotético, workers adicionais poderiam terminar mais pedidos em paralelo, mas encontrar o mesmo limite de conexões no banco.
Há mais de uma forma de ajustar capacidade
Antes de ampliar a infraestrutura, pode ser mais simples reduzir trabalho desnecessário: revisar consultas lentas, evitar chamadas repetidas, limitar o processamento de dados a cada solicitação ou armazenar em cache informações que mudam pouco. O objetivo é tratar a causa observada, não presumir que todo problema de desempenho pede mais máquinas.
Quando é preciso aumentar recursos, há duas opções comuns. Escalar verticalmente é dar mais capacidade a um recurso existente, como CPU ou memória. Escalar horizontalmente é adicionar instâncias para dividir o trabalho. Essas definições e os critérios para escolher entre elas estão descritos nas recomendações oficiais de escalabilidade da Microsoft.
A escala vertical pode ser direta, mas depende do limite do recurso e pode exigir uma mudança de configuração ou interrupção. A horizontal pode distribuir solicitações, desde que a aplicação e seus dados estejam preparados para mais de uma instância. Ela também exige observar o que essas instâncias compartilham, como banco, cache e APIs. A capacidade desses componentes precisa acompanhar a estratégia.
Filas ajudam quando parte do trabalho pode esperar
Uma fila pode receber tarefas que não precisam terminar durante a resposta ao usuário. Um worker as processa depois, conforme a capacidade disponível. A documentação da Microsoft sobre nivelamento de carga com filas descreve esse padrão para separar produtores de consumidores e absorver variações temporárias na demanda.
A fila organiza o trabalho; não elimina limites. Se as tarefas chegarem mais rápido do que os workers conseguem concluí-las por um período prolongado, o volume pendente e o tempo de espera aumentam. Acompanhe essa fila, defina como tratar falhas e evite efeitos duplicados quando uma mensagem precisar ser processada novamente. Nem toda operação pode ser adiada: o que precisa de resposta imediata deve continuar dentro do objetivo de tempo definido.
Teste a carga que importa e acompanhe a operação
Testes de carga devem representar uma combinação plausível de acessos, operações e tarefas, incluindo períodos de pico que façam sentido para o negócio. Observe latência, erros e volume processado junto com os recursos que podem limitar o fluxo: consultas, conexões, cotas de API e acúmulo de tarefas. Compare os resultados com os objetivos estabelecidos e repita os testes quando mudanças importantes alterarem o sistema.
Em produção, acompanhe as mesmas medidas e configure alertas para os limites relevantes. Se houver ajuste automático de capacidade, registre o que dispara a ação e estabeleça limites para evitar expansão desnecessária. Uma métrica isolada, como CPU, pode não revelar uma dependência lenta ou uma fila crescente; monitorar a aplicação e os serviços dos quais ela depende ajuda a localizar o problema.
Escalar na medida do negócio
Nem toda empresa precisa projetar para crescimento extremo ou adotar desde o início uma arquitetura distribuída. Uma solução simples pode atender bem à demanda atual e prevista. A decisão depende do padrão de carga, do impacto de uma lentidão, do tempo aceitável de espera, dos limites conhecidos e do custo de operar cada opção.
Mais capacidade pode elevar despesas; várias instâncias, filas e componentes distribuídos também trazem trabalho de configuração, monitoramento e manutenção. Uma arquitetura escalável procura equilibrar esse custo e essa complexidade com os objetivos definidos. Ela não garante disponibilidade: tolerar falhas e recuperar um serviço exige medidas próprias, como redundância e procedimentos de recuperação adequados ao risco, conforme os princípios de projeto de aplicações do Azure. Também não garante vendas ou outro resultado de negócio.
Escalabilidade trata da relação entre carga, capacidade e desempenho. Questões como preservação de dados e troca de informações entre sistemas pedem avaliações próprias. Para decidir se um sistema precisa escalar, comece pela demanda observada, pelos limites que ela encontra e pelo nível de serviço que a empresa precisa sustentar.
