Fundamentos de Sistemas Distribuídos

10:00:00 — as vendas abrem

• Em uma máquina, a função retornou ou lançou exceção — a pergunta não existiria.
• O BoxOffice roda em dezenas de máquinas ligadas apenas por uma rede.
• Um sistema distribuído: nós que cooperam só por mensagens, sem memória e sem relógio compartilhados.

"Um sistema distribuído é aquele em que a falha de um computador que você nem sabia que existia pode tornar o seu próprio computador inutilizável." — Leslie Lamport

Por que distribuir — e o que custa

Em escala, falhar é a regra: 1 − (1 − p)^N. Com p = 0,1% por máquina por dia, 3.000 máquinas veem uma falha em ~95% dos dias.

Modelos de falha

As 8 falácias da computação distribuída

1. A rede é confiável
2. A latência é zero — mesmo DC ≈ 0,5 ms de RTT, entre continentes ≈ 150 ms
3. A largura de banda é infinita
4. A rede é segura
5. A topologia não muda
6. Existe um administrador
7. O custo de transporte é zero
8. A rede é homogênea

Deutsch et al., Sun Microsystems (1994; Gosling acrescentou a 8ª em 1997). Cada uma volta em uma aula posterior.

Lento ou morto?

inventory → payment: autorizar R$ 450 … silêncio … timeout após 2 s.

• (a) requisição perdida · (b) payment caiu · (c) resposta perdida · (d) payment só lento
• Os quatro casos são idênticos para quem chama.
• Um timeout permite supor a falha — não saber.
• Em (c) e (d) a cobrança aconteceu: um retry cego cobra duas vezes.

Semânticas de entrega

Efetivamente uma vez = entrega pelo menos uma vez + processamento idempotente.

Tornando retries seguros

• Idempotente: aplicar duas vezes = aplicar uma. GET, PUT, DELETE sim; POST, x = x + 1 não.
• Escrita condicional (compare-and-set): a duplicata não muda nada.

UPDATE seats SET status = 'HELD', fan_id = 42, hold_key = :key
 WHERE id = 'A-12' AND (status = 'FREE' OR hold_key = :key);

• Chave de idempotência: o cliente envia um UUID por ação pretendida; o servidor grava chave + resultado na mesma transação e repete o resultado guardado diante de uma duplicata.
• Guarde as chaves em armazenamento compartilhado — o retry cai em outra réplica.

Modelos de replicação

Quando dizer OK: assíncrona (rápida, pode perder escritas no failover) · síncrona (o seguidor mais lento decide) · semissíncrona / quórum (o meio-termo usual).

Atraso de replicação na vida real

• Dia tranquilo, atraso médio de 20 ms → quase nunca desatualizado.
• Abertura das vendas, atraso médio de 800 ms → desatualizado para ~69% das fãs aos 300 ms (modelo exponencial, ilustrativo).
• Sob carga, o bug não é raro — é esperado.

O espectro de consistência

• Linearizável para assentos, dinheiro, unicidade, líderes.
• Garantias de sessão via leitura no líder após escrita, tokens de LSN, réplicas fixas.
• Conflitos eventuais: LWW (perde escritas), vetores de versão, CRDTs.

CAP: durante uma partição, escolha

PACELC: o trade-off que você paga todo dia

Partição → A ou C; senão (Else) → Latência ou Consistência.

Por isso: síncrona entre zonas (EC), assíncrona ou particionada por região de origem entre regiões (EL). Ordens de grandeza ilustrativas.

BoxOffice: uma escolha por domínio de dados

Multirregião: cada evento tem uma região de origem (a do local do show) — a consistência forte fica local, e uma partição só afeta reservas entre regiões.

Consenso: concordar sobre um log

• Máquina de estado replicada: mesmos comandos, mesma ordem → mesmo estado em todo nó.
• Segurança sempre (nunca duas decisões diferentes); vivacidade quando a rede se comporta.
• FLP: nenhum algoritmo determinístico sempre termina num sistema assíncrono → timeouts.
• Maiorias se sobrepõem → sem split brain.

Use 3 ou 5 nós, espalhados de modo que nenhuma zona tenha a maioria. Dois nós a 99% cada = 98,01%.

Raft em um slide

• Seguidor → Candidato → Líder; tempo dividido em termos, no máximo um líder por termo.
• Sem heartbeat por um election timeout (aleatório) → vira candidato, term + 1, pede votos.
• Um voto por termo; só vota em um log pelo menos tão atualizado (restrição de eleição).
• O líder acrescenta, replica com AppendEntries, confirma depois que uma maioria gravou em disco.
• Um líder desatualizado vê um termo maior → volta a ser seguidor.

Padrões do etcd: heartbeat de 100 ms, election timeout de 1.000 ms → a queda de um líder custa ~1–2 s sem escritas. Usado por etcd, Consul, CockroachDB, Kafka KRaft.

Quóruns sem líder: R + W > N

Leases precisam de fencing tokens

1. O worker A obtém o lease, token 33 — então uma pausa de GC de 15 s; o lease expira.
2. O worker B obtém o lease, token 34, escreve com 34.
3. A acorda, ainda "tem o lock", escreve com 33 → o armazenamento rejeita 33 < 34.

UPDATE scheduled_jobs SET last_run_at = now(), fencing_token = :token
 WHERE job_id = 'onsale-reminder-42' AND fencing_token <= :token;

Atômico entre serviços? Two-phase commit

1. Prepare: cada participante grava suas mudanças + um registro prepared, mantém os locks, vota sim/não.
2. Commit: todos sim → o coordenador registra COMMIT e avisa todos; algum não → ABORT.

O 2PC continua vivo dentro de bancos distribuídos com coordenador replicado (Spanner, CockroachDB, transações do Kafka) — não entre microsserviços.

Sagas: compensar em vez de travar

• Orquestrada (um cérebro, p. ex. order ou Temporal) ou coreografada (eventos).
• Sem isolamento → locks semânticos com expiração; todo passo idempotente.
• Cada passo grava banco + evento atomicamente com um outbox transacional.

Sem relógio global

• O quartzo deriva: 20 ppm ≈ 1,7 s/dia; o NTP mantém os servidores a ~ms — se continuar rodando.
• Relógio de parede (currentTimeMillis) pode pular → só para timestamps humanos.
• Relógio monotônico (nanoTime) → durações, timeouts.

Ordenar sem confiar em relógios

O mapa de conceitos

Todo componente do playground herda um desses problemas — pergunte qual antes de colocá-lo num projeto.

Takeaways

1. Distribua só por escala, tolerância a falhas, latência, isolamento, residência; falhar vira a regra.
2. Lento ≈ morto para quem chama: timeouts + retries idempotentes (escritas condicionais, chaves de idempotência).
3. Entrega exatamente uma vez é impossível → pelo menos uma vez + processamento idempotente.
4. Escolha um modelo de consistência por domínio de dados: linearizável para assentos e dinheiro, read-your-writes para os dados do usuário, eventual para o catálogo.
5. CAP nas partições, PACELC todo dia; particione por região de origem; sagas + outbox, não 2PC, entre serviços.
6. Maiorias (3 ou 5 nós), Raft, R + W > N, fencing tokens — use o etcd, não o construa.
7. Nunca ordene eventos por timestamps de máquinas diferentes.