Scaling

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

Escalar um sistema é resolver um problema de capacidade: mais tráfego, mais dados, mais usuários simultâneos. A armadilha é investir em infraestrutura para um problema que ainda não existe. A postura correta: construir com base sólida e escalar quando os dados indicarem necessidade.

Aumentar a capacidade da máquina: mais CPU (Central Processing Unit · Unidade Central de Processamento), mais RAM (Random Access Memory · Memória de Acesso Aleatório), disco mais rápido.

Vantagens: zero mudança de código e zero complexidade de infraestrutura. Resolve a maioria dos gargalos de um sistema em crescimento.

Limite: existe um teto físico e financeiro. Uma máquina maior sempre custa mais do que duas máquinas menores com a mesma capacidade somada.

Quando usar: como primeiro passo de qualquer escala. Meça, identifique o gargalo, aumente o recurso correspondente. Passe para a escala horizontal quando o teto vertical for atingido ou quando o custo se tornar proibitivo.

Adicionar mais instâncias da aplicação e distribuir a carga entre elas.

Requisito central: a aplicação precisa ser stateless (sem estado local). Estado em memória (sessão, cache local, WebSocket com estado) impede a replicação, porque cada requisição precisa poder cair em qualquer instância e produzir o mesmo resultado.

Como tornar a aplicação stateless:

Com a aplicação stateless, adicionar instâncias tem efeito linear: duas instâncias dobram a capacidade, dez multiplicam por dez.

O Load Balancer (balanceador de carga) distribui as requisições entre as instâncias disponíveis, e é o ponto de entrada da escala horizontal.

O balanceador consulta periodicamente um endpoint de cada instância (GET /health) e remove da rotação as que não respondem ou respondem com erro, até que se recuperem.

Load Balancer → GET /health → 200 OK → instância saudável, recebe tráfego
Load Balancer → GET /health → timeout → instância removida da rotação

O balanceador recebe o tráfego HTTPS (HyperText Transfer Protocol Secure · Protocolo Seguro de Transferência de Hipertexto), descriptografa e repassa HTTP (HyperText Transfer Protocol · Protocolo de Transferência de Hipertexto) simples para as instâncias internas. O gerenciamento de certificados fica centralizado no balanceador.

Cliente → HTTPS → Load Balancer (SSL termination) → HTTP → Instâncias

O API Gateway é o ponto de entrada único para todos os serviços de uma API (Application Programming Interface · Interface de Programação de Aplicações). Ele centraliza responsabilidades que, sem ele, teriam de ser implementadas em cada serviço.

Responsabilidades centrais:

Cliente → API Gateway → autenticação → rate check → roteamento → Serviço A | Serviço B

O API Gateway é infraestrutura de entrada: faz pré-processamento e roteamento, e deixa a lógica de negócio para os serviços.

Ferramentas comuns: AWS API Gateway, Kong, Nginx, Traefik, Caddy.

Além de instâncias e balanceadores, existem camadas de escala que dispensam servidores novos:

CDN para assets estáticos: imagens, JS, CSS e fontes servidos a partir de nós geograficamente próximos ao usuário, sem carga nenhuma no servidor de aplicação.

Cache na borda: respostas de API guardadas no Redis ou Memcached, de modo que as requisições repetidas param antes de chegar ao banco.

Requisição → Cache hit → resposta em < 1ms
Requisição → Cache miss → banco → armazena → resposta

Read replicas: em sistemas com muito mais leitura do que escrita, as réplicas de leitura absorvem as queries SELECT sem tocar na instância primária.

Escrita → banco primário
Leitura → read replica 1 | read replica 2 | read replica N

Filas para absorver picos: em vez de processar operações lentas de forma síncrona, enfileire e processe em background. O servidor de aplicação responde rápido e o worker (processo que executa tarefas em segundo plano) absorve o pico no seu próprio ritmo.

A maioria dos projetos nunca vai precisar de escala horizontal, balanceador dedicado ou várias read replicas. Investir nessa infraestrutura antes de ter o problema custa complexidade e não entrega nada em troca.

Sequência correta:

1. Monolito Modular + escala vertical
2. Otimizar queries e adicionar cache quando os dados indicarem
3. Adicionar load balancer e tornar stateless quando o tráfego exigir
4. Considerar read replicas quando leitura virar gargalo no banco
5. Microsserviços apenas quando limites de domínio ou times impuserem isolamento real

Cada etapa só faz sentido depois que a anterior se esgotou. Pular etapas aumenta a complexidade sem benefício proporcional.

Sinais de que é hora de escalar:

O que evitar no início:

DoDocs v3.7.0 · Desenvolvido por @thiagocajadev · Baseado no trabalho de pmndrs/docs · Poimandres.