Visão geral

Imagine a loja que você vai construir neste curso rodando como uma única aplicação Spring Boot, com um único banco PostgreSQL, em uma única máquina. É simples de entender — até o tráfego crescer além do que essa máquina aguenta, ou a máquina cair e levar a loja inteira junto. No momento em que você divide o trabalho entre várias máquinas (um gateway, um serviço de contas, um serviço de pedidos, um banco de dados, um cache, um broker de mensagens), você construiu um sistema distribuído, e surge uma nova classe de problemas.

Sistemas distribuídos representam um paradigma de computação em que vários computadores independentes colaboram para atingir um objetivo comum, aparecendo para o usuário final como um único sistema coerente³. Diferentemente dos sistemas centralizados, em que todo o processamento ocorre em uma máquina, os sistemas distribuídos se estendem por redes e usam nós interconectados (um nó é qualquer computador ou processo independente que participa do sistema) para cuidar do armazenamento de dados, da computação e da comunicação.

Essa arquitetura sustenta as plataformas de nuvem modernas (AWS, Google Cloud, Azure), as aplicações de larga escala (redes sociais, e-commerce) e as simulações científicas. O desafio fundamental é que os nós operam de forma independente, se comunicam apenas trocando mensagens e não têm um relógio compartilhado — o que torna a coordenação um problema de engenharia nada trivial.

Roteiro

1. Esta visão geral — o que é um sistema distribuído, por que os construímos, quanto eles custam e os três problemas de raiz (falha parcial, rede não confiável, ausência de relógio global).
2. Teorema CAP — a escolha entre consistência e disponibilidade durante uma partição de rede, e sua extensão PACELC.
3. Consenso e algoritmos — como os nós concordam sobre um valor apesar de falhas: FLP, modelos de falha, Paxos, Raft, quóruns e CRDTs.
4. Quiz — verifique o que você entendeu.

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

Nossa loja é um sistema distribuído

Um único clique em "Finalizar pedido" na loja já atravessa a rede várias vezes. Acompanhe a requisição:

flowchart LR
    user([Navegador]) -->|POST /orders| gw[Gateway]
    gw -->|valida o token| auth[Serviço de autenticação]
    gw -->|encaminha| order[Serviço de pedidos]
    order -->|verifica o estoque| product[Serviço de produtos]
    product -->|preço em cache| redis[(Redis)]
    order -->|INSERT do pedido| pg[(PostgreSQL)]
    order -->|OrderCreated| kafka[[Kafka]]

Cada seta é uma mensagem pela rede, e cada caixa é um processo que pode falhar sozinho. Se o serviço de produtos estiver lento, o serviço de pedidos espera; se o Kafka estiver fora do ar, o pedido pode ser gravado, mas o evento nunca é publicado. Nada nesse desenho compartilha memória ou relógio — os serviços cooperam apenas trocando mensagens. Essa é exatamente a definição de sistema distribuído, e é por isso que o restante desta aula importa para o projeto.

Classificação

Sistemas distribuídos podem ser classificados segundo vários eixos:

Aplicações web seguem o modelo cliente-servidor (navegadores fazem requisições a servidores). Sistemas de compartilhamento de arquivos como o BitTorrent seguem o modelo peer-to-peer. A maioria das arquiteturas de microsserviços ocupa o meio-termo fracamente acoplado: nossa loja é heterogênea (serviços em Java, um serviço de notificação em Python, PostgreSQL, Redis, Kafka), fracamente acoplada (os serviços conversam por HTTP e Kafka) e cliente-servidor (o navegador chama o gateway, e o gateway chama os serviços).

Vantagens

Na loja, a escalabilidade horizontal é o que o Hands-on 7 faz com o Nginx na frente de várias réplicas de um serviço, e a redução de latência é o que o cache Redis do Hands-on 8 oferece.

Desvantagens

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

L. Peter Deutsch e colegas da Sun Microsystems² listaram as suposições que os desenvolvedores costumam fazer ao construir sistemas distribuídos — todas erradas (a lista tinha sete itens em 1994; James Gosling acrescentou a oitava, a rede é homogênea, em 1997):

Os três problemas de raiz

Quase toda dificuldade deste curso remonta a três fatos.

1. Falha parcial

Em uma única máquina, um programa funciona ou cai como um todo. Em um sistema distribuído, parte do sistema pode falhar enquanto o restante continua rodando: o serviço de produtos está fora do ar, mas o gateway e o serviço de pedidos estão bem. Cada componente precisa decidir o que fazer quando uma de suas dependências para de responder.

2. Uma rede não confiável: lento ou morto?

Quando o serviço de pedidos envia uma requisição e não recebe resposta, ele não tem como saber o que aconteceu. Considere as possibilidades:

sequenceDiagram
    participant O as Serviço de pedidos
    participant P as Serviço de produtos
    O->>P: reservar 1 unidade do produto 42
    Note over O,P: requisição perdida? P caiu? resposta perdida? P só está lento?
    O-->>O: timeout após 2 s
    O->>P: retry: reservar 1 unidade do produto 42
    P-->>O: OK (mas a primeira também foi aplicada?)

Do ponto de vista de quem chama, uma requisição perdida, um servidor que caiu, uma resposta perdida e um servidor muito lento parecem iguais: silêncio. A única ferramenta prática é um timeout — depois de um prazo, assume-se a falha. Mas um timeout não diz se a operação foi executada, então um retry pode aplicá-la duas vezes. Por isso, operações que podem ser repetidas precisam ser idempotentes (aplicá-las duas vezes tem o mesmo efeito que aplicá-las uma vez — por exemplo, enviando um id único de requisição que o servidor usa para descartar duplicatas). Timeouts, retries com backoff e circuit breakers são abordados em Padrões de resiliência.

3. Ausência de relógio global

Cada máquina tem seu próprio relógio de quartzo, e os relógios derivam: dois servidores sincronizados com NTP (Network Time Protocol) ainda podem discordar em milissegundos, e muito mais depois de uma configuração errada ou de uma pausa da VM. Assim, você não consegue ordenar de forma confiável dois eventos em máquinas diferentes comparando seus horários de relógio — um pedido criado "às 10:00:00.120" em um nó pode, na verdade, ter acontecido depois de um cancelamento registrado "às 10:00:00.150" em outro.

Tempo e ordenação: relógios lógicos

Leslie Lamport¹ observou que, na maioria dos casos, não precisamos do horário real dos eventos — precisamos da sua ordem, e especificamente da relação aconteceu-antes (happened-before, →):

• se a e b acontecem no mesmo processo e a vem primeiro, então a → b;
• se a é o envio de uma mensagem e b o seu recebimento, então a → b;
• se a → b e b → c, então a → c.

Dois eventos em que nenhum aconteceu antes do outro são concorrentes: nenhum deles pode ter influenciado o outro.

Um relógio de Lamport é um contador mantido por cada processo, atualizado com três regras:

1. Antes de cada evento local, incremente o contador.
2. Ao enviar uma mensagem, anexe o valor atual do contador.
3. Ao receber uma mensagem com valor t, ajuste o contador para max(local, t) + 1.

sequenceDiagram
    participant A as Serviço de pedidos
    participant B as Consumidor Kafka
    participant C as Notificação
    Note over A: cria o pedido (L=1)
    A->>B: OrderCreated (L=2)
    Note over B: recebe: max(0,2)+1 = 3
    Note over C: evento local (L=1)
    B->>C: SendEmail (L=4)
    Note over C: recebe: max(1,4)+1 = 5

A garantia é: se a → b, então L(a) < L(b). A recíproca não é verdadeira — um timestamp de Lamport menor não prova que um evento causou o outro. Os relógios vetoriais resolvem isso mantendo um contador por processo; comparar dois vetores diz se um evento aconteceu antes do outro ou se eles são concorrentes. Eles são usados para detectar escritas conflitantes em bancos de dados replicados (veja Consistência eventual).

Tópicos abordados

Conexões

• Microsserviços — dividir a loja em serviços é o que a transforma em um sistema distribuído.
• Arquitetura orientada a eventos e Hands-on 9 — mensageria assíncrona com Kafka, ordenada pelos offsets das partições.
• Confiabilidade — timeouts, retries, circuit breakers: projetar para a falha parcial.
• Hands-on 7 e Hands-on 8 — escalabilidade horizontal atrás de um balanceador de carga, e um cache Redis.
• Hands-on 10 — rastreamento distribuído, para ver uma requisição atravessando muitos serviços.

Pontos-chave

• Um sistema distribuído é um conjunto de nós independentes que cooperam apenas trocando mensagens e não têm relógio compartilhado; nossa loja vira um assim que tem mais de um serviço.
• Distribuímos para ganhar escalabilidade, tolerância a falhas e latência — e pagamos em complexidade, falhas de rede e custo operacional.
• As 8 falácias são todas falsas: projete toda chamada remota para a falha.
• Quem chama não consegue distinguir um nó lento de um nó morto: use timeouts e torne idempotentes as operações repetidas.
• Relógios físicos derivam; ordene eventos com uma única autoridade ou com relógios lógicos (Lamport, relógios vetoriais).