System design advanced

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

Avançado em relação a system-design.md. Este documento cobre os instrumentos quantitativos e os teoremas que orientam decisões em sistemas distribuídos.

Projetar sistemas em escala exige vocabulário preciso: acordos de nível de serviço, modelos de consistência, teoremas de distribuição, estimativas de capacidade. Cada um responde uma pergunta específica que System Design conceitual não resolve sozinho.

Três termos frequentemente confundidos. A distinção é operacional:

A relação entre os três:

SLI (número medido) → SLO (meta interna) → SLA (promessa externa)

O SLI é a realidade observada. O SLO é uma meta mais apertada que o SLA para dar margem de segurança. O SLA é o compromisso com o cliente.

Exemplo prático:

Quando o SLI passa do SLO, o time age antes de violar o SLA.

O complemento de um SLO é o error budget (orçamento de erro): a margem de falha aceita dentro da meta. Uma disponibilidade de 99.9% concede 43 minutos de indisponibilidade por mês. Enquanto o budget não estoura, o time pode assumir risco (deploy arriscado, mudança estrutural). Quando estoura, congela mudanças até recuperar margem.

Em sistemas distribuídos, partições de rede são inevitáveis. O teorema CAP formaliza que, sob partição, é obrigatório escolher entre:

Não existe sistema CA em produção real: partição não é opcional, é uma propriedade da rede.

CAP só fala do que acontece durante partição. PACELC completa o quadro:

Partition → Availability vs Consistency
Else     → Latency     vs Consistency

Leitura: "se houver Partição, escolha entre A e C; senão (Else), escolha entre L e C".

Classificar um sistema pelo PACELC é mais informativo que pelo CAP sozinho.

Consistência não é binária. Existem níveis intermediários úteis:

Modelos mais fracos toleram latência e partição melhor. Modelos mais fortes custam coordenação. Escolher o modelo correto por operação, não por sistema inteiro.

Cálculo aproximado que cabe em um guardanapo e evita decisões de infraestrutura baseadas em intuição. Valores de referência úteis:

Exemplo: sistema com 10 milhões de usuários ativos por mês, cada um fazendo 20 ações por dia:

10M usuários × 20 ações × 30 dias = 6 bilhões de ações por mês
6B / 2.592.000 segundos ≈ 2.300 ações por segundo (médio)
Pico típico = 3× média = 7.000 QPS

Esse número define se uma instância resolve, se precisa de sharding, se o banco aguenta. Decidir sem o cálculo é adivinhar.

Particionar dados entre nós por uma chave de partição. Cada shard (partição) guarda uma fatia do conjunto total.

Sharding resolve escala de escrita. Para escala de leitura, usar réplicas. As duas combinam: shards replicados.

Aprofundamento em tuning de banco fica em ../platform/database.md; técnicas de escala aplicada em scaling.md.

Manter cópias dos mesmos dados em múltiplos nós. Cada cópia atende leituras; escritas precisam de coordenação.

Quórum: em sistema leaderless, se escritas requerem W nós e leituras R nós, e W + R > N (total), leituras sempre veem a última escrita confirmada.

Os dois conceitos são ortogonais e combináveis:

Sistemas reais combinam: cada shard é replicado, cada réplica cobre um shard. Cassandra e MongoDB seguem essa topologia.

Antes de considerar o design concluído:

Itens pendentes indicam decisões ainda implícitas. Tornar explícito evita descobertas em produção.

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