Na nuvem, um servidor maior se contrata em minutos. Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia, considera que essa facilidade esconde a pergunta central da escalabilidade: até onde vale aumentar a máquina antes de multiplicar as máquinas.
As duas respostas têm nome técnico. Escalar verticalmente significa dar mais processador, memória ou disco a um mesmo servidor. Escalar horizontalmente significa distribuir a carga entre várias instâncias, que trabalham em paralelo e podem ser adicionadas ou retiradas conforme a demanda.
Nenhuma das duas é superior em todas as situações. Cada uma troca simplicidade por flexibilidade em proporções diferentes, e a escolha errada costuma aparecer tarde, quando o custo de corrigi-la já é alto. Nos próximos parágrafos, você encontrará os critérios que ajudam a decidir.
O que se ganha e o que se perde ao crescer verticalmente?
A principal vantagem da escala vertical é não exigir mudança no código. Uma aplicação escrita para rodar em um único servidor continua funcionando igual em uma máquina mais potente, sem que a equipe precise redesenhar sessões, filas ou acesso a dados.
Jean Pierre Lessa e Santos Ferreira nota que essa comodidade tem prazo de validade. Os tipos de instância têm um teto, e o preço cresce mais rápido que a capacidade nas configurações mais altas. Chega um ponto em que dobrar o investimento não dobra o desempenho.
Há ainda a questão da disponibilidade. Um servidor único, por maior que seja, continua sendo um ponto único de falha. Além disso, muitos redimensionamentos exigem reiniciar a máquina, o que obriga a agendar janelas de manutenção fora dos horários de maior movimento.
O que a escala horizontal exige da aplicação?
Pense num site de varejo que guarda o carrinho do cliente na memória do servidor. Se o próximo clique cair em outra instância, o carrinho some. Por isso, a escala horizontal pede aplicações sem estado, com sessões guardadas em serviços externos e compartilhados.
Cumprido esse requisito, os ganhos são expressivos. Um balanceador distribui as requisições, o autoescalonamento acrescenta instâncias nos picos e as remove depois, e a queda de uma máquina afeta só parte do tráfego. A capacidade passa a acompanhar a demanda quase em tempo real.
A dificuldade maior está na camada de dados. Bancos relacionais não se dividem com a mesma facilidade que servidores de aplicação. Réplicas de leitura aliviam consultas, mas a escrita continua concentrada, e particionar os dados entre vários bancos exige decisões de modelagem difíceis de desfazer.
Critérios para decidir entre um modelo e outro
Jean Pierre Lessa e Santos Ferreira observa que raramente a decisão vale para o sistema inteiro. Em operações de varejo com picos sazonais, a camada web tende a crescer horizontalmente, enquanto o banco de dados principal costuma ganhar máquinas maiores antes de ser particionado.
O padrão de carga é o segundo critério. Demanda estável e previsível tolera bem a escala vertical, porque a capacidade pode ser dimensionada com antecedência. Demanda com picos curtos e intensos favorece a horizontal, já que pagar por uma máquina enorme o ano inteiro para atender poucos dias sai caro.
O terceiro critério é a maturidade da equipe. Operar dezenas de instâncias exige automação de implantação, observabilidade distribuída e disciplina para tratar falhas parciais. Sem essa base, a escala horizontal troca um problema de capacidade por um problema de operação.
A escolha certa muda conforme o sistema amadurece
Poucos sistemas nascem prontos para crescer em várias instâncias, e isso não é um defeito. Começar com escala vertical permite validar o produto com rapidez. O erro está em não perceber o momento em que essa opção deixa de ser atalho e vira obstáculo.
Um bom sinal de alerta é o custo por transação. Quando cada novo degrau de máquina encarece o atendimento de um pedido sem melhorar o tempo de resposta na mesma proporção, a escala vertical já entregou o que podia, e o investimento rende mais na distribuição da carga.
Em última análise, Jean Pierre Lessa e Santos Ferreira conclui que a arquitetura madura costuma combinar os dois modelos, cada um aplicado à camada em que rende mais. A decisão deixa de