Visão geral

São 10:00:00 e o show no estádio abre as vendas. Dois milhões de fãs apertam "Reservar assento" no app do BoxOffice praticamente no mesmo segundo, e 60.000 assentos precisam ser divididos entre eles — cada assento vendido exatamente uma vez. Uma fã, dentro do trem, aperta o botão, o spinner gira por cinco segundos e o app mostra "Algo deu errado, tente novamente". Ela aperta de novo. A primeira requisição reservou um assento? Ela está prestes a reservar dois? Vai ser cobrada duas vezes?

Em uma única máquina essa pergunta não existiria: a função retornou ou lançou uma exceção. O BoxOffice, porém, roda em dezenas de máquinas — gateways, várias réplicas do serviço inventory, um PostgreSQL replicado, Redis, um cluster Kafka — e a única coisa que as conecta é uma rede capaz de perder, atrasar e duplicar mensagens. Isso faz do BoxOffice um sistema distribuído, e esta aula trata do que isso muda.

Um sistema distribuído é um conjunto de computadores independentes (nós) que cooperam apenas trocando mensagens por uma rede, sem memória compartilhada e sem relógio compartilhado, e que aparecem para seus usuários como um único sistema coerente¹. A definição meio em tom de brincadeira de Leslie Lamport é a mais útil para um engenheiro: "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"².

Roteiro

1. Esta visão geral — por que distribuir, o que isso custa, modelos de falha, a rede não confiável (8 falácias), timeouts, semânticas de entrega e idempotência.
2. Replicação e Consistência — replicação com um líder, com vários líderes e sem líder; o espectro de consistência, de linearizável a eventual; garantias de sessão como read-your-writes.
3. CAP e PACELC — a escolha entre consistência e disponibilidade durante uma partição, a escolha entre latência e consistência no resto do tempo, e projetos multirregião.
4. Consenso e Quóruns — maiorias, Raft (eleição e replicação do log), R + W > N, leases e fencing tokens, e as ferramentas que fazem isso por você.
5. Transações Distribuídas — atomicidade entre serviços: two-phase commit e por que ele bloqueia, sagas com compensações, reservas try–confirm–cancel e o outbox transacional.
6. Tempo e Relógios — NTP e deriva de relógio, relógios de Lamport e vetoriais, relógios lógicos híbridos, TrueTime e como ordenar eventos na prática.
7. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Por que distribuir?

Ninguém distribui um sistema por diversão: um único processo com um único banco de dados é mais fácil de escrever, testar, depurar e entender. Só pagamos o preço da distribuição quando uma máquina não consegue mais atender a um requisito não funcional:

Escalar verticalmente — uma máquina maior — é a primeira resposta e, por um tempo, muitas vezes a certa. Ela para de funcionar por três motivos: existe uma maior máquina que se pode comprar; no topo, o preço cresce mais rápido que a capacidade; e, por maior que seja, ela continua sendo uma máquina — um ponto único de falha (SPOF, single point of failure).

Em escala, falhar é a regra

O segundo argumento esconde um paradoxo: distribuir para tolerar falhas significa usar mais máquinas, e mais máquinas significam mais falhas. Se cada máquina falha em um dado dia com uma pequena probabilidade \(p\), de forma independente, a probabilidade de que pelo menos uma de \(N\) máquinas falhe nesse dia é \(1 - (1-p)^N\):

Com uma chance (ilustrativa) de 0,1% de falha por máquina por dia, três máquinas veem uma falha em cerca de 0,3% dos dias, mas uma frota de 3.000 máquinas vê pelo menos uma falha em cerca de 95% dos dias. Os primeiros relatos do Google descrevem exatamente essa experiência: na escala de uma frota, falhas de hardware são rotina diária, não exceção³. A conclusão molda o resto do curso: um sistema distribuído precisa tratar a falha como um evento normal e continuar funcionando apesar dela — não dá para esperar evitá-la.

O que a distribuição custa

O BoxOffice é um sistema distribuído

Acompanhe um clique em "Reservar assento A-12" pelo BoxOffice. Cada seta é uma mensagem pela rede; cada caixa é um processo que pode falhar, pausar ou ficar lento por conta própria:

flowchart LR
    fan([Celular do fã]) -->|"POST /holds"| gw[gateway]
    gw -->|"valida o token"| auth[auth]
    gw -->|"encaminha"| inv[inventory]
    inv -->|"UPDATE seat ... (transação)"| pg[("PostgreSQL primário")]
    pg -->|"replica o WAL"| rep[("PostgreSQL réplica")]
    inv -->|"cacheia o mapa de assentos"| redis[("Redis")]
    inv -->|"evento SeatHeld"| kafka[["Kafka (3 brokers)"]]
    kafka -->|"consome"| notif[notification]

Nada nessa figura compartilha memória ou relógio. Se o Redis está lento, o inventory espera; se a réplica está atrasada, uma leitura nela está desatualizada; se o Kafka está inacessível, a reserva pode ter sido confirmada no PostgreSQL, mas o evento SeatHeld nunca publicado. Cada um desses casos é uma falha parcial, e o resto desta página trata de nomeá-las com precisão.

Modelos de falha

Um modelo de falha diz o que um componente defeituoso pode fazer. Ele importa porque todo algoritmo só é correto sob algum modelo: um protocolo que tolera crashes pode ser enganado por um nó que mente.

Mais duas ideias completam o vocabulário:

• Falha parcial: em uma máquina, um programa normalmente funciona ou cai por inteiro. Em um sistema distribuído, parte dele falha enquanto o resto continua rodando, e ninguém tem uma visão completa de qual parte. As falhas cinza, estudadas pela Microsoft no Azure, são o pior caso — o monitoramento do próprio sistema discorda dos usuários⁴.
• Hipóteses de tempo: em um modelo síncrono, mensagens e processamento têm limites superiores conhecidos; em um modelo assíncrono, não há limite algum. Redes reais são parcialmente síncronas: comportam-se bem na maior parte do tempo, com atrasos ocasionais sem limite (um switch congestionado, uma pausa de GC, a migração de uma VM). Algoritmos práticos (o Raft, por exemplo) são projetados para serem seguros sob assincronia e para progredir apenas quando a rede se comporta.

A rede não é confiável

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

Nos anos 1990, L. Peter Deutsch e colegas da Sun Microsystems listaram as suposições que iniciantes em sistemas distribuídos fazem — todas falsas⁵:

Cada uma delas aparece em aulas posteriores: a falácia 1 em Confiabilidade, a 2 em Estimativas, a 3 em Tráfego e Borda, a 4 em Rede e Segurança, a 5 em Cloud-native.

Lento ou morto?

Quando o inventory envia uma requisição ao payment e nenhuma resposta chega, ele não tem como saber qual destes casos aconteceu:

sequenceDiagram
    participant I as inventory
    participant P as payment
    I->>P: autorizar R$ 450 (requisição 1)
    Note over I,P: (a) requisição perdida  (b) payment caiu<br/>(c) resposta perdida  (d) payment só está lento
    I-->>I: sem resposta após 2 s: timeout
    I->>P: autorizar R$ 450 (retry)
    P-->>I: OK
    Note over I,P: nos casos (c) e (d) o fã foi cobrado duas vezes

Do lado de quem chama, uma requisição perdida, um servidor que caiu, uma resposta perdida e um servidor muito lento parecem a mesma coisa: silêncio. A única ferramenta prática é um timeout — depois de um prazo, supor que houve falha. Mas um timeout não diz se a operação foi executada, e daí decorrem duas coisas:

1. Escolher o timeout é um trade-off. Longo demais e as threads de quem chama se acumulam esperando (a falha em cascata de Confiabilidade); curto demais e você declara mortos nós saudáveis mas lentos, faz retry e adiciona carga justamente quando o sistema está sofrendo. Um ponto de partida comum é um pouco acima da latência p99,9 do serviço chamado, dentro do orçamento de latência de quem chama. Sistemas como Cassandra e Akka vão além e usam detectores de falha adaptativos (o detector φ accrual), que aprendem a distribuição normal dos atrasos dos heartbeats⁷.
2. Retries precisam ser seguros. Se o retry pode aplicar a operação uma segunda vez, isso precisa ser inofensivo — a operação precisa ser idempotente.

Semânticas de entrega e idempotência

No máximo uma vez, pelo menos uma vez, exatamente uma vez

Sempre que uma mensagem atravessa uma rede não confiável, o remetente escolhe uma semântica de entrega:

"Entrega exatamente uma vez" por uma rede não confiável é impossível em geral — o remetente nunca pode ter certeza de que o destinatário não processou uma mensagem cuja confirmação se perdeu. O que sistemas como o Kafka chamam de exactly-once é processamento exatamente uma vez: duplicatas podem chegar, mas seu efeito é aplicado uma vez, por deduplicação ou transações⁸. A aula de Mensageria aprofunda o tema.

Operações idempotentes

Uma operação é idempotente se aplicá-la várias vezes tem o mesmo efeito que aplicá-la uma vez: \(f(f(x)) = f(x)\).

Duas técnicas tornam seguras para retry as operações não idempotentes:

1. Reescrever como uma transição de estado com condição (compare-and-set): "marque o assento como HELD se ele estiver FREE", "grave a versão 8 se a versão atual for 7". Uma duplicata não satisfaz a condição e não muda nada.
2. Chaves de idempotência: o cliente gera uma chave única por operação pretendida e a envia em todas as tentativas; o servidor guarda a chave junto com o resultado e, diante de uma duplicata, devolve o resultado guardado em vez de executar de novo. A API pública do Stripe popularizou o cabeçalho Idempotency-Key⁹, e há um rascunho do IETF padronizando-o.

sequenceDiagram
    participant F as App do fã
    participant O as order
    participant DB as PostgreSQL
    F->>O: POST /orders, Idempotency-Key: 7f3a…
    O->>DB: INSERT da chave 7f3a… (única) + pedido 981
    DB-->>O: confirmado (commit)
    O--xF: 201 Created (resposta perdida no trem)
    F->>O: retry: POST /orders, Idempotency-Key: 7f3a…
    O->>DB: INSERT da chave 7f3a…
    DB-->>O: violação de unicidade: a chave já existe
    O->>DB: SELECT da resposta guardada para 7f3a…
    O-->>F: 201 Created, pedido 981 (o mesmo pedido, sem duplicata)

A chave e a mudança de negócio precisam ser gravadas na mesma transação; caso contrário, um crash entre as duas escritas reabre a janela para duplicatas:

CREATE TABLE idempotency_keys (
    key           UUID PRIMARY KEY,
    request_hash  TEXT        NOT NULL,   -- reject the same key with a different body
    response      JSONB,                  -- what we answered the first time
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

BEGIN;
INSERT INTO idempotency_keys (key, request_hash)
VALUES ('7f3a…', 'sha256:…')
ON CONFLICT (key) DO NOTHING;            -- 0 rows inserted → duplicate: return stored response
INSERT INTO orders (id, fan_id, total) VALUES (981, 42, 450.00);
UPDATE idempotency_keys SET response = '{"orderId": 981}' WHERE key = '7f3a…';
COMMIT;

// ---- strategy 3: optimistic, compare-and-set on a version column ---------------
private void holdOptimistic(long eventId, List<Long> seatIds, UUID holdId) {
    var seats = read(eventId, seatIds, "");                      // no lock
    requireAvailable(seats, seatIds);
    for (var seat : seats) {
        int changed = jdbc.sql("""
                UPDATE inventory.seats
                SET status = 'HELD', hold_id = :holdId, version = version + 1
                WHERE id = :id AND version = :version AND status = 'AVAILABLE'""")
                .param("holdId", holdId).param("id", seat.id()).param("version", seat.version())
                .update();
        if (changed == 0) {
            // someone changed this seat after we read it: give up (the exception rolls back)
            throw new ResponseStatusException(HttpStatus.CONFLICT, "seat " + seat.id() + " was just taken");
        }
    }
}

public Result charge(String idempotencyKey, ChargeRequest req) {
    Optional<PaymentOut> done = find(idempotencyKey);
    if (done.isPresent()) {
        return new Result(done.get(), false); // a retry: answer, do not charge again
    }
    // remote call OUTSIDE any database transaction: never hold a connection while waiting
    PspClient.Charge charge = psp.charge(idempotencyKey, req.amount(), "order-" + req.orderId());
    String status = "approved".equals(charge.status()) ? "AUTHORIZED" : "DECLINED";
    jdbc.sql("""
            INSERT INTO payments (id, idempotency_key, order_id, amount, status, provider_ref)
            VALUES (?, ?, ?, ?, ?, ?)
            ON CONFLICT (idempotency_key) DO NOTHING
            """)
            .params(UUID.randomUUID(), idempotencyKey, req.orderId(), req.amount(), status, charge.id())
            .update();
    return new Result(find(idempotencyKey).orElseThrow(), true);
}

Juntando tudo: o mapa de conceitos

Os três problemas de raiz — falha parcial, uma rede não confiável e nenhum relógio global — explicam quase todas as decisões de projeto do resto do curso. O mapa abaixo liga cada problema às técnicas desta aula (azul), à subpágina que as ensina e aos componentes da paleta em que você as encontrará no playground (verde):

flowchart LR
    PF["Falha parcial"]:::problem --> REP["Replicação<br/>(manter cópias)"]
    NET["Rede não confiável"]:::problem --> IDEM["Timeouts, retries,<br/>idempotência"]
    CLK["Sem relógio global"]:::problem --> ORD["Ordenação:<br/>relógios lógicos / híbridos"]
    REP --> CM["Modelos de consistência<br/>linearizável … eventual"]
    CM --> CAP["CAP / PACELC<br/>C vs A, L vs C"]
    CAP --> CONS["Consenso, quóruns,<br/>fencing"]
    IDEM --> TX["Sagas, outbox,<br/>2PC"]
    CONS --> TX
    ORD --> CONS
    REP -.-> sql["sql · nosql"]:::comp
    CM -.-> cache["cache · cdn"]:::comp
    CONS -.-> kafka["kafka · scheduler"]:::comp
    IDEM -.-> pay["payment · queue"]:::comp
    TX -.-> stream["stream · kafka"]:::comp
    CAP -.-> dns["dns (multirregião)"]:::comp
    classDef problem fill:#e5484d22,stroke:#e5484d
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed
    class REP,IDEM,ORD,CM,CAP,CONS,TX tech

Pontos-chave

O que quebra em seguida

O BoxOffice agora tem o vocabulário para sobreviver à rede entre suas máquinas — timeouts, retentativas idempotentes, um modelo de consistência por domínio de dados, consenso para escolher o primário. Ainda não decidiu quem recebe o tráfego. Às 10:00:00 dois milhões de celulares mandam uma requisição no mesmo segundo: cerca de 100.000 requisições/s na borda (a estimativa), enquanto uma instância do catalog medida no laboratório 2 mantém a meta de p99 só até algumas centenas de requisições por segundo. A maioria dessas requisições precisa terminar antes de qualquer serviço, o resto precisa chegar a uma réplica saudável, e os bots não podem chegar primeiro: aula 4 — Tráfego e Borda.

Relacionados

• Playground: System Design Playground — todo componente deste curso pode falhar; ligue o caos (data-chaos) em qualquer cenário.
• Hands-on: Hands-on 7 — Assíncrono (consumidor idempotente, outbox), Hands-on 9 — Resiliência e caos (timeouts, retries, injeção de falhas com Toxiproxy).
• Exercícios: Event-driven (consumidor idempotente), Design doc.
• Estudos de caso: Ingressos (abertura de vendas do BoxOffice), Sistema de pagamentos, Cache distribuído.
• Aulas: Estimativas (números de latência), Bancos de dados — replicação, Mensageria — semânticas, Confiabilidade.
• Preparação para entrevistas: Entrevista.