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 é tentar resolver antecipadamente um problema que ainda não existe. A postura correta: construir com base sólida, 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, zero complexidade de infraestrutura. Resolve a maioria dos gargalos de um sistema em crescimento.

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

Quando usar: primeiro passo de qualquer escala. Medir, identificar o gargalo, aumentar o recurso correspondente. Só partir para escala horizontal quando o teto vertical for atingido ou o custo se tornar proibitivo.

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

Requisito central: a aplicação deve ser stateless (sem estado local). Estado em memória (sessão, cache local, WebSocket com estado) impede a replicação. Cada requisição deve poder cair em qualquer instância sem diferença de resultado.

Como tornar a aplicação stateless:

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

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

O balanceador consulta periodicamente um endpoint de cada instância (GET /health). Instâncias que não respondem ou respondem com erro são removidas da rotação automaticamente até se recuperar.

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. As instâncias não precisam gerenciar certificados; o balanceador centraliza isso.

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

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

Responsabilidades centrais:

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

O API Gateway não executa lógica de negócio. É infraestrutura de entrada: pré-processamento e roteamento.

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

Além de instâncias e balanceadores, há camadas de escala que não exigem mais servidores:

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

Cache na borda: respostas de API cacheadas no Redis ou Memcached. Requisições repetidas não chegam ao banco.

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

Read replicas: para sistemas com muito mais leitura do que escrita, réplicas de leitura distribuem 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, enfileirar e processar em background. O servidor de aplicação responde rápido; o worker (trabalhador) absorve o pico no seu próprio ritmo.

A maioria dos projetos nunca vai precisar de escala horizontal, load balancer dedicado ou múltiplas read replicas. A decisão errada é investir nessa infraestrutura antes de ter o problema.

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 fronteiras de domínio ou times impuserem isolamento real

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

Sinais de que é hora de escalar:

O que não fazer no início:

Desenvolvido por @thiagocajadev · Fork baseado no repositório pmndrs/docs · Poimandres.