System Design/01 - Fundamentos2 min
How to approach System Design
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Um método que funciona tanto em entrevista quanto em projeto real. A ordem importa: quem começa desenhando caixas antes de saber os números desenha o sistema errado.
1. Esclarecer requisitos (não pule)
- Funcionais: o que o sistema precisa fazer? Liste as 3-5 operações centrais.
- Não-funcionais: quantos usuários, qual latência aceitável, qual disponibilidade, leitura ou escrita pesada?
- Fora de escopo: diga explicitamente o que você não vai resolver.
2. Estimar a escala
Números aproximados mudam o design inteiro:
DAU × ações por usuário = requisições/dia
requisições/dia ÷ 86.400 = RPS médio
RPS médio × 2 a 10 = RPS de pico
registros × tamanho × retenção = armazenamento
Razão leitura:escrita é a estimativa mais decisiva — 100:1 justifica cache e réplicas de leitura; 1:1 muda tudo.
3. Definir a API
Assinaturas das operações principais. Isso força a concordar sobre o que o sistema faz antes de discutir como.
4. Modelo de dados
Entidades, relacionamentos, e padrões de acesso. O padrão de acesso decide o banco — não o contrário.
5. Desenho de alto nível
Cliente → DNS → CDN → load balancer → serviço → cache → banco. Ligue só o necessário.
6. Aprofundar onde há tensão
Escolha 1-2 pontos e vá fundo: particionamento, consistência do cache, tratamento de hot key.
7. Gargalos e falhas
Para cada componente: o que acontece se ele cair? E se ficar lento? Onde está o SPOF?
Trade-offs
O método é sequencial, mas a realidade é iterativa: a estimativa de escala frequentemente invalida o modelo de dados, que invalida o desenho. Voltar é sinal de rigor, não de erro.
O erro oposto também existe: gastar tempo demais em requisitos e não sobrar para o design. Em entrevista, o orçamento razoável é ~20% em requisitos e escala, ~50% no desenho, ~30% aprofundando.
Exemplo prático
"Projete o Twitter", em números, antes de qualquer caixa:
300M DAU · 2 tweets/dia → 600M escritas/dia ≈ 7.000 escritas/s
cada usuário lê 100 tweets/dia → 30B leituras/dia ≈ 350.000 leituras/s
razão leitura:escrita ≈ 50:1
Esses três números já dizem o design: leitura domina → fan-out na escrita, cache agressivo do timeline, e o banco de escrita pode ser bem menor que o de leitura. Sem eles, a discussão vira preferência pessoal.
Relacionado
Parte de Introduction · roadmap.sh/system-design