System Design/01 - Fundamentos2 min
Performance vs Scalability
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Dois problemas frequentemente confundidos.
- Performance: o sistema está lento para um usuário. Você tem um problema de performance.
- Escalabilidade: o sistema está lento à medida que a carga cresce. Você tem um problema de escalabilidade.
A definição operacional: um sistema é escalável quando adicionar recursos aumenta a capacidade proporcionalmente. Se dobrar as máquinas dobra o throughput, escala. Se dobrar as máquinas aumenta 20%, não escala — há um gargalo compartilhado.
| Performance | Escalabilidade | |
|---|---|---|
| Sintoma | Lento com 1 usuário | Lento com N usuários |
| Causa típica | Algoritmo, query, I/O | Contenção, recurso compartilhado, coordenação |
| Solução | Otimizar o caminho | Remover o gargalo, particionar |
Vertical vs horizontal
| Vertical (scale up) | Horizontal (scale out) | |
|---|---|---|
| Como | Máquina maior | Mais máquinas |
| Limite | Teto físico do hardware | Praticamente ilimitado |
| Complexidade | Baixa | Alta (estado, coordenação, consistência) |
| Disponibilidade | SPOF | Tolera falha de nó |
| Custo | Cresce super-linearmente | Cresce linearmente |
Trade-offs
Escalabilidade horizontal só é possível se o sistema for stateless ou se o estado for particionável. É por isso que "tire o estado da aplicação" é o conselho mais repetido: sessão em memória do processo transforma qualquer sistema num sistema não-escalável.
A Lei de Amdahl limita o ganho: se 10% do trabalho é serial, nenhum paralelismo passa de 10x. E a Lei de Universal Scalability vai além — a partir de certo ponto, adicionar nós piora o desempenho, porque o custo de coordenação entre eles cresce mais rápido que a capacidade.
Escalar vertical primeiro é frequentemente a decisão certa: é barato, imediato, e adia complexidade real. O erro é tratar isso como estratégia permanente.
Exemplo prático
Uma API responde em 800 ms com um usuário. Adicionar servidores não resolve — o problema é performance (provavelmente uma query sem índice).
A mesma API responde em 50 ms com 100 usuários e 4 s com 10.000. Adicionar servidores ajuda até o ponto em que todos disputam o mesmo banco; aí o gargalo migra, e a solução deixa de ser "mais servidores" e passa a ser réplica de leitura, cache ou particionamento.
Relacionado
Parte de 01 - MOC Fundamentos · roadmap.sh/system-design