Sistemas Descentralizados/01 - Fundamentos4 min
Tipos de Sistemas Distribuídos
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
"Distribuído" e "descentralizado" são usados como sinônimos e não são. A distinção que importa:
- Distribuído = o trabalho está em várias máquinas.
- Descentralizado = o controle está em várias mãos.
O Google é o sistema mais distribuído do mundo e é totalmente centralizado: um dono, uma decisão. Dá para ser distribuído sem ser descentralizado, e o inverso quase não existe.
O eixo útil para classificar, então, não é "quantas máquinas" — é de quem você precisa confiar e quem pode entrar sem pedir licença.
Os cinco tipos
1. Distribuído centralizado — um operador, N máquinas
O caso normal do dia a dia. Postgres com réplicas, Kafka, etcd, seu monolito atrás de um load balancer, tudo que você estuda em 00 - MOC System Design. As máquinas confiam umas nas outras porque têm o mesmo dono. O adversário aqui é apenas o hardware falhando e a rede caindo — ninguém está mentindo de propósito.
Por isso o consenso é barato: Raft e Paxos assumem crash fault tolerance (nó cai ou atrasa, mas não mente) e precisam de maioria simples, N/2 + 1.
2. Federado — N operadores, protocolo comum
Vários servidores independentes, de donos diferentes, falando o mesmo protocolo. Cada servidor é autoridade sobre os seus próprios usuários e conversa com os outros.
Exemplos: e-mail (SMTP) — o caso de sucesso de 40 anos —, Matrix, XMPP, ActivityPub (Mastodon).
Aqui aparece a característica que define federação: sua identidade contém o servidor. giovani@gmail.com, @user@mastodon.social. Isso é conveniente e é a fraqueza estrutural: o servidor faz parte de quem você é, então se ele morre ou te bane, você perde o endereço e recomeça.
3. P2P puro — nós iguais, sem servidor
Todo nó é cliente e servidor. Não há hierarquia. Exemplos: BitTorrent, IPFS, DHTs como Kademlia.
Ótimo para distribuir conteúdo imutável e endereçado por hash. Ruim para o resto: nós domésticos estão atrás de NAT, ficam offline, e a descoberta de quem tem o quê custa saltos na rede. Na prática quase todo P2P "puro" tem uma muleta centralizada — tracker, bootstrap node, gateway.
4. Relay + chave pública — servidores burros e descartáveis
O modelo do 1. Nostr, e o mais recente dos cinco. A jogada: manter a infraestrutura cliente-servidor (que funciona, atravessa NAT, é fácil de hospedar) mas tirar a identidade do servidor e colocar num par de chaves.
O servidor (relay) fica deliberadamente burro: guarda e entrega mensagens assinadas, e não decide nada. Como sua identidade não depende dele, ele se torna intercambiável. Se um te bane, os outros continuam te servindo — e você não "migrou", porque nunca esteve preso.
5. Blockchain / Web3 — estado global replicado, membresia aberta
O extremo. Todo nó guarda o estado inteiro e re-executa toda transação para chegar ao mesmo resultado, sob a suposição de que os outros participantes podem estar mentindo de propósito (falha bizantina) e que qualquer um pode entrar sem permissão.
É o único dos cinco que mantém um estado global com ordem única e acordada. É também, de longe, o mais caro. Ver 1. Web3 e Blockchain.
A tabela que resume
| Centralizado | Federado | P2P | Relay (Nostr) | Blockchain | |
|---|---|---|---|---|---|
| Confiança necessária | 1 operador | seu servidor | nenhuma | nenhuma | nenhuma |
| Membresia | fechada | semi-aberta | aberta | aberta | permissionless |
| Identidade mora | no banco | no servidor | no nó | na chave | na chave |
| Consenso | Raft/Paxos | nenhum | nenhum | nenhum | Nakamoto/BFT |
| Estado global | sim | não | não | não | sim |
| Ordem global | sim | não | não | não | sim |
| Custo de escrita | µs | ms | ms | ms | $ + minutos |
| Adversário previsto | hardware | um operador ruim | par malicioso | qualquer operador | maioria coordenada |
A última linha é a mais importante da nota. Cada degrau compra resistência a um adversário diferente, e paga em performance e complexidade. Descentralização não é um gradiente moral onde mais é melhor — é uma escolha de modelo de ameaça.
Trade-offs
O trade-off geral: quanto menos confiança você exige, menos o sistema consegue afirmar.
| Você abre mão de… | E perde a capacidade de… |
|---|---|
| Operador único | garantir que o dado existe amanhã |
| Consenso | ter ordem única e contagens confiáveis |
| Identidade em banco | recuperar conta perdida |
| Estado global | fazer agregações, joins, "quantos?" |
Repare que essas perdas não são bugs a serem consertados em versões futuras — são o preço estrutural do que se ganhou. Um sistema sem consenso não vai "resolver a ordenação depois"; ele escolheu não ter esse problema, e junto com ele não ter essa capacidade.
O erro clássico de projeto na área é escolher o degrau pelo apelo ideológico e depois passar anos reimplementando, mal, as garantias que se jogou fora.
Exemplo prático
Mesmo requisito — "um app de mensagens" — nos cinco modelos:
| Modelo | Como fica | Quem pode te silenciar |
|---|---|---|
| Centralizado | WhatsApp. Rápido, simples, ótimo UX. | A empresa |
| Federado | Matrix. Você escolhe (ou hospeda) o servidor. | O admin do seu servidor |
| P2P | Só funciona se os dois estiverem online ao mesmo tempo. | Ninguém — e nada funciona |
| Relay | Nostr. Publica em 5 relays, lê de 5 relays. | Ninguém sozinho |
| Blockchain | Cada mensagem é uma transação paga e pública para sempre. | Ninguém — e custa caro demais |
Nas duas pontas o resultado é ruim por motivos opostos: o centralizado funciona bem e te deixa exposto; o blockchain te protege e não funciona para esse caso. O interessante está no meio — e é exatamente por isso que Nostr existe.
Relacionado
Parte de MOC Fundamentos Distribuídos