Escalabilidade
Escala vertical e horizontal, e o que precisa mudar no sistema para ele aceitar mais máquinas.
O que é escalar
Um sistema atende bem mil usuários por dia. Uma campanha traz cem mil num fim de semana. As respostas ficam lentas, depois começam os erros, e o sistema cai no momento em que mais pessoas tentam usá-lo.
Escalabilidade é a capacidade de atender mais carga acrescentando recursos, sem reescrever o sistema. A palavra-chave é acrescentando: um sistema escalável não é o que aguenta qualquer carga, mas o que tem um caminho claro para aguentar mais.
Carga pode significar coisas diferentes, e cada uma pressiona uma parte do sistema:
| Tipo de carga | Exemplo | O que pressiona |
|---|---|---|
| Requisições por segundo | Mais usuários navegando ao mesmo tempo | CPU e memória da aplicação |
| Volume de dados | Milhões de pedidos acumulados | Banco de dados, índices, disco |
| Trabalho por requisição | Relatórios pesados, processamento de imagens | CPU, tempo de resposta |
| Conexões abertas | Notificações em tempo real | Memória e limites de conexão |
Duas direções: para cima e para os lados
| Escala vertical | Escala horizontal | |
|---|---|---|
| O que é | Uma máquina maior: mais CPU, mais memória | Mais máquinas iguais, dividindo a carga |
| Mudança no código | Nenhuma | A aplicação precisa funcionar em várias cópias |
| Limite | A maior máquina disponível | Praticamente nenhum na aplicação; o gargalo vai para outro lugar |
| Falhas | A máquina é um ponto único de falha | Uma cópia cai e as outras continuam |
| Custo | Máquinas grandes custam desproporcionalmente mais | Cresce de forma mais linear |
| Velocidade para aplicar | Exige reiniciar numa máquina maior | Acrescentar uma cópia leva segundos ou minutos |
A escala vertical é subestimada. Um servidor moderno tem dezenas de núcleos e centenas de gigabytes de memória, e muitos sistemas nunca precisam de mais que isso. Ela também é a forma mais comum de escalar bancos de dados relacionais, que são difíceis de dividir.
A escala horizontal é o caminho para a aplicação, porque não tem teto e traz tolerância a falhas junto: com três cópias, a queda de uma passa despercebida.
A condição para escalar horizontalmente
Para várias cópias dividirem a carga, um balanceador de carga distribui os pedidos entre elas. Um pedido pode cair em qualquer cópia, e o próximo pedido do mesmo usuário pode cair em outra.
Isso só funciona se qualquer cópia conseguir atender qualquer pedido. A aplicação precisa ser sem estado (stateless): nada que importe para os próximos pedidos pode ficar guardado na memória ou no disco de uma cópia específica.
Testamos isso com duas cópias de um servidor atrás de um Nginx, que alterna os pedidos entre elas. O carrinho do usuário foi guardado primeiro num mapa na memória do processo:
adicionar teclado → instancia-a: ["teclado"]
ver carrinho → instancia-b: [] ← vazio
ver carrinho → instancia-a: ["teclado"]
ver carrinho → instancia-b: [] ← vazio de novoO item foi guardado na memória da cópia A. Cada pedido que caía na cópia B via um carrinho vazio. Com o carrinho guardado no Redis, compartilhado pelas duas, todos os pedidos passaram a ver o mesmo conteúdo.
O mesmo problema aparece com tudo o que mora dentro da instância:
| Estado guardado na instância | O que acontece com várias cópias |
|---|---|
| Sessão do usuário na memória | O usuário é deslogado quando o pedido cai em outra cópia |
| Arquivo enviado gravado no disco local | O arquivo só existe numa cópia, e some quando ela é substituída |
| Cache em memória sem invalidação | Cada cópia mostra uma versão diferente do dado |
| Tarefa agendada no próprio processo | Com cinco cópias, o relatório diário é gerado cinco vezes |
| Contador ou limite de requisições na memória | Cada cópia conta só os seus pedidos, e o limite fica multiplicado |
O gargalo se move
Acrescentar cópias da aplicação aumenta a capacidade até que outra parte se torne o limite. Quase sempre, essa parte é o banco de dados: dez cópias da aplicação mandam dez vezes mais consultas para o mesmo banco.
Escalar é um ciclo: encontrar o gargalo atual, aliviá-lo e descobrir o próximo. Por isso medir vem antes de escalar. Acrescentar cópias da aplicação quando o gargalo é uma consulta sem índice só aumenta a fila no banco.
Elasticidade
Na nuvem, as cópias podem ser acrescentadas e removidas automaticamente conforme a carga: mais de dia, menos de madrugada, muitas durante uma promoção. Isso se chama escala automática.
Ela traz duas exigências novas. Cópias precisam iniciar rápido, para chegar a tempo de atender o pico. E precisam sair sem derrubar pedidos: quando a carga cai e uma cópia é removida, os pedidos que ela estava atendendo precisam terminar. O nível Implementação mostra como.
Por que isso importa quando a IA escreve o código
Um assistente escreve código que funciona perfeitamente numa única instância. Os problemas aparecem quando o sistema ganha uma segunda cópia:
- Sessões, carrinhos e contadores ficam em variáveis na memória do processo.
- Arquivos enviados são gravados numa pasta local.
- Uma tarefa agendada roda dentro da aplicação e se repete em cada cópia.
- O processo não trata o sinal de encerramento, e cada deploy derruba pedidos em andamento.
- A primeira reação a uma lentidão é acrescentar máquinas, sem medir onde está o gargalo.
O próximo nível compara as formas de escalar cada parte do sistema e o que precisa mudar para escalar horizontalmente.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escalabilidade em cinco minutos
Explique em no máximo cinco minutos de leitura o que é escalabilidade no backend, para alguém que programa mas sempre rodou a aplicação numa única máquina. Cubra só o essencial: a diferença entre escala vertical e horizontal, por que a aplicação precisa ser sem estado para rodar em várias cópias, e por que o gargalo costuma ir para o banco de dados. Use o exemplo de uma loja que recebe dez vezes mais visitas numa promoção. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
Vertical, horizontal e o gargalo que se move
Quero entender as formas de escalar um sistema e como o gargalo muda de lugar. Aja como um mentor de backend. Pergunte primeiro qual é a minha experiência e como o sistema em que eu trabalho está implantado. Conduza assim, uma etapa por vez: 1. Explique escala vertical e horizontal, com vantagens, limites e custos de cada uma. 2. Descreva um sistema com uma aplicação e um banco recebendo o dobro de carga a cada mês, e pergunte o que eu faria em cada etapa. 3. Mostre como o gargalo passa da aplicação para o banco, e do banco para outro lugar. 4. Explique a diferença entre melhorar a latência de um pedido e aumentar a capacidade do sistema. Faça uma pergunta de verificação em cada etapa e espere a minha resposta antes de continuar.
Encontrar o estado escondido na aplicação
Quero aprender a reconhecer o estado guardado na instância, que impede a aplicação de rodar em várias cópias. Explique por que uma aplicação precisa ser sem estado para escalar horizontalmente, com o exemplo de um carrinho guardado na memória do processo e um balanceador que alterna os pedidos entre duas cópias. Depois me mostre oito trechos de código ou de configuração, um por vez, e pergunte se cada um causa problema com várias cópias. Inclua: sessão em memória, upload gravado em pasta local, cache em memória sem invalidação, tarefa agendada no processo, limite de requisições em memória, conexões WebSocket, configuração lida de um arquivo editável, e dois trechos corretos. Corrija cada resposta e diga para onde aquele estado deveria ir.
Elasticidade e cópias descartáveis
Quero entender o que muda quando as cópias da aplicação entram e saem automaticamente. Explique: 1. O que é escala automática e quais métricas costumam guiá-la. 2. Por que as cópias precisam iniciar rápido, e o que torna uma aplicação lenta para iniciar. 3. O que acontece com os pedidos em andamento quando uma cópia é removida, se a aplicação não fizer nada. 4. A diferença entre verificação de vivacidade e de prontidão. 5. A ideia de tratar servidores como descartáveis, e não como máquinas a serem cuidadas uma a uma. Faça perguntas de verificação ao longo da explicação.