Pular para o conteúdo

apps/architecture/peer-to-peer

038 · Arquiteturas de Alto Nível (Macro-Architecture) · ≈ 6 min de estudo

Peer-to-Peer

Os nós falam direto entre si, sem servidor central nem broker: cada banco é ao mesmo tempo cliente e servidor. A rede sobrevive à queda de qualquer nó, mas cada nó precisa resolver sozinho o que um coordenador resolveria — entrega, duplicidade, quem está vivo. Use quando não pode haver ponto único de falha ou dono central da infraestrutura.

passos
6
arquivos
4
testes
0
tecnologias
2
Lógica puraTypeScriptBun
Baixar cartão

Cenário

Quatro bancos em linha trocam liquidações interbancárias direto, ponto a ponto, e propagam alertas de fraude por gossip. O Alpha liquida R$ 50.000,00 com o Delta sem passar por ninguém; um alerta de fraude do Alpha chega ao Delta pelos vizinhos. Quando o Gamma cai, o Beta percebe pelo silêncio e a rede fica partida em duas.

Planta

Fluxo
4/4
Banco AlphaREP 5761, PUB 5762Banco BetaREP 5763, PUB 5764Banco GammaREP 5765, PUB 5766Banco DeltaREP 5767, PUB 5768gossip PUB/SUB+ heartbeatgossip PUB/SUB+ heartbeatgossip PUB/SUB+ heartbeatliquidacaodireta REQ/REP
4

4 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Nós iguais, sem servidor central.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    Cada nó faz bind do próprio REP (liquidação) e PUB (gossip e heartbeat) e connect do SUB só nos vizinhos

  2. 02

    Liquidação é REQ/REP direto com o destino; no timeout o REQ travado é fechado e um novo tenta de novo (Lazy Pirate), até esgotar as tentativas — aí o valor fica reservado como "em dúvida", nunca devolvido como se não tivesse saído

  3. 03

    O receptor aplica cada txId uma vez: a retentativa depois de uma resposta perdida não credita duas vezes

  4. 04

    O alerta de fraude se espalha por epidemia: cada nó guarda e reencaminha só o que ainda não viu, com TTL, e a rota registra por onde passou

  5. 05

    PUB/SUB descarta o que foi publicado antes de o assinante conectar (slow joiner): o gossip só começa depois de cada nó ver o heartbeat dos vizinhos

  6. 06

    Vizinho sem heartbeat por mais de peerDownAfterMs é dado como fora — sem coordenador avisando

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Sem broker nem servidor central: nenhum ponto único de falha

  • Liquidação direta, sem salto intermediário

  • Gossip alcança toda a rede só com ligações entre vizinhos

  • Um nó novo entra conhecendo só os vizinhos

Custos

  • Cada nó implementa retentativa, deduplicação e detecção de falha

  • Liquidação sem resposta fica em dúvida e exige reconciliação

  • Queda de um nó de passagem particiona a rede

  • PUB/SUB não persiste: mensagem para nó fora do ar se perde

apps/architecture/peer-to-peer

4 arquivos

src/

  • node_bank.tsNó do banco: liquidação REQ/REP com retentativa, gossip com seen-set, heartbeat
  • topology_bank.tsOs quatro bancos, portas e ligações da linha
  • zmq_ffi.tsBinding bun:ffi da libzmq: sockets não bloqueantes, linger 0
  • demo.tsdemoLiquidação, gossip e queda de um nó

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários

Pré-requisito: a biblioteca libzmq5 no sistema (apt-get install -y libzmq5). O pacote npm zeromq não carrega no Bun; src/zmq_ffi.ts abre a libzmq com bun:ffi.

Requisitos
Bun

Por que se relacionam

Teste rápido

Qual destes combina com Peer-to-Peer?

Próximo projeto · Arquiteturas de Alto Nível (Macro-Architecture)Arquitetura em Camadas (N-Tier)
Esc

↑ ↓ navegarEnter abrir191 resultados