O que é um Sistema Distribuído

Conceito

Um sistema distribuído é um conjunto de componentes rodando em máquinas independentes, que se comunicam por rede e se apresentam ao usuário como um sistema só.

A definição parece inofensiva. A consequência não é. Leslie Lamport resumiu melhor que ninguém:

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

Por que distribuir

Ninguém distribui por gosto. Distribui-se por um destes quatro motivos:

Se nenhum desses aperta, uma máquina só é a resposta certa — e é muito mais barata de operar.

Guarde o quarto motivo: é ele que gera Web3 e Nostr. Os três primeiros são técnicos; o quarto é político, e produz arquiteturas muito diferentes.

As três coisas que mudam quando você atravessa a rede

Este é o núcleo do assunto. Numa máquina só, três coisas são de graça — e distribuindo, todas somem:

1. Falha parcial. Numa máquina, ou o programa roda ou não roda. Distribuído, uma parte funciona e outra não — e você não sabe qual. Pior: "não respondeu" é indistinguível de "está lento", de "morreu depois de fazer o trabalho" e de "a rede comeu a resposta". Você nunca tem certeza; só tem timeout.

2. Não existe relógio global. Cada máquina tem seu relógio, e eles divergem (clock skew). Dizer "esse evento aconteceu antes daquele" deixa de ser fato observável e vira escolha de modelagem — daí vêm relógios lógicos, vector clocks e a obsessão da área com ordem causal em vez de ordem temporal.

3. Não existe estado global observável. Você não consegue tirar uma "foto" do sistema inteiro num instante: enquanto lê a máquina A, a B já mudou. Todo estado que você observa é passado.

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

Lista da Sun Microsystems (Peter Deutsch e James Gosling). Cada item é uma suposição que todo mundo faz sem perceber e que o sistema cobra depois:

1. A rede é confiável
2. A latência é zero
3. A 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

Vale ler como checklist de revisão de arquitetura: para cada uma, pergunte "e se não for verdade aqui?".

Trade-offs

Ganha-se escala, disponibilidade e proximidade. Perde-se a capacidade de raciocinar sobre o sistema. Num processo único você abre o debugger e olha o estado; distribuído, você tem logs de cinco serviços com relógios desalinhados e precisa reconstruir a história.

O trade-off menos intuitivo é estatístico: mais máquinas significam mais falhas, não menos. Com 1.000 máquinas de 99,9% de disponibilidade individual, a chance de todas estarem saudáveis num instante é ~37%. Ou seja: no seu sistema alguma coisa está sempre quebrada.

Isso inverte a lógica da programação sequencial. Distribuído, você não escreve o caminho feliz e trata erro depois — o tratamento de falha é o design.

Exemplo prático

O serviço A chama o B para cobrar um cartão, com timeout de 2 segundos. O timeout estoura.

O que aconteceu? Pode ser:

• B nunca recebeu o pedido — nada foi cobrado
• B recebeu, cobrou, e a resposta se perdeu na volta — foi cobrado
• B está lento e vai cobrar daqui a 3 segundos — vai ser cobrado
• B caiu no meio do processamento — talvez cobrado

A não tem como distinguir esses casos. Nenhuma informação disponível para A resolve a ambiguidade. Se A tentar de novo, pode cobrar duas vezes; se não tentar, pode não cobrar nunca.

A saída não é adivinhar melhor — é mudar o problema: tornar a operação idempotente, com uma chave gerada por A, de modo que repetir seja seguro. Por isso Idempotent Operations não é refinamento avançado: é a resposta direta à falha parcial, que é a característica definidora de sistema distribuído.

Relacionado

• 2. Tipos de Sistemas Distribuídos
• CAP Theorem
• Idempotent Operations

---

Parte de MOC Fundamentos Distribuídos · As 8 falácias