Redes Distribuidas

Sem CDN:                         Com CDN (ex: Cloudflare):
  Brasil ---[200ms]---> US        Brasil ---[5ms]---> Edge SP
  (servidor unico nos EUA)                           |
                                                      |-- cache hit? Serve!
                                                      |-- cache miss? Busca no origin

CDN funciona com:
  1. DNS retorna IP do edge server mais proximo (anycast)
  2. Edge server verifica cache local
  3. Cache hit: serve diretamente (latencia minima)
  4. Cache miss: busca no origin server, cacheia, serve

Anycast routing (como CDN encontra o server mais próximo):
  ┌─────────────┐
  │  Mesmo IP:  │     Usuário em SP → roteado para Edge SP
  │ 104.16.1.1  │     Usuário em NY → roteado para Edge NY
  │             │     Usuário em Tóquio → roteado para Edge JP
  └─────────────┘
  O BGP roteia para o datacenter mais próximo
  porque múltiplos datacenters anunciam o mesmo IP

Estratégia         Header HTTP              Comportamento
─────────────      ────────────────────     ─────────────────────────────
TTL fixo           Cache-Control: max-age   Edge serve do cache até expirar
Revalidação        ETag + If-None-Match     Edge pergunta ao origin se mudou
Stale-while-       stale-while-revalidate   Serve stale, atualiza em background
  revalidate
Purge manual       API da CDN               Operador invalida cache sob demanda
Cache busting      URL versionada           app.v2.js (nova URL = novo cache)

Exemplo de headers HTTP para cache de CDN:
  Cache-Control: public, max-age=86400, stale-while-revalidate=3600
  ETag: "abc123"
  Vary: Accept-Encoding

Algoritmo               Descricao                        Uso
─────────────────       ──────────────────────────       ──────────────
Round-robin             Alterna entre instancias         Simples, uniforme
Least connections       Envia para quem tem menos conn.  Instancias heterogeneas
Weighted round-robin    Round-robin com pesos             Instancias diferentes
IP hash                 Mesmo IP sempre para mesma inst. Sessoes sticky
Consistent hashing      Distribui por hash, minimo       Caches distribuidos
                        reshuffling quando inst. muda

Tipos de load balancer por camada OSI:
  L4 (Transporte): roteia por IP/porta (rápido, sem inspeção de conteúdo)
  L7 (Aplicação):  roteia por URL, headers, cookies (mais flexível)

import hashlib

class ConsistentHashRing:
    """Consistent hashing para distribuição de carga.
    Minimiza redistribuição quando nodes são adicionados/removidos."""

    def __init__(self, nodes, replicas=100):
        self.ring = {}
        self.sorted_keys = []
        for node in nodes:
            for i in range(replicas):
                key = self._hash(f"{node}:{i}")
                self.ring[key] = node
                self.sorted_keys.append(key)
        self.sorted_keys.sort()

    def _hash(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16)

    def get_node(self, key):
        """Encontra o node responsável por esta chave."""
        h = self._hash(key)
        for ring_key in self.sorted_keys:
            if h <= ring_key:
                return self.ring[ring_key]
        return self.ring[self.sorted_keys[0]]

# Uso: distribuir requests entre 3 servidores
ring = ConsistentHashRing(["server-a", "server-b", "server-c"])
print(ring.get_node("user-123"))   # server-b (sempre o mesmo)
print(ring.get_node("user-456"))   # server-a

Service Mesh (padrao sidecar):

┌──────────────────┐          ┌──────────────────┐
│ Service A        │          │ Service B        │
│ (sua aplicacao)  │          │ (sua aplicacao)  │
│        |         │          │        |         │
│  [Sidecar Proxy] │---mTLS---│  [Sidecar Proxy] │
│  (Envoy)         │          │  (Envoy)         │
└──────────────────┘          └──────────────────┘

O sidecar cuida de:
  - mTLS automatico entre servicos
  - Retries e timeouts
  - Circuit breaking
  - Observabilidade (metricas, traces)
  - Load balancing
  - Rate limiting

Exemplos: Istio (Kubernetes), Linkerd, Consul Connect

Arquitetura control plane vs data plane:
  Data plane:    Sidecar proxies (Envoy) — processa tráfego
  Control plane: Istiod/Linkerd — configura proxies, distribui certs

Padroes de comunicacao entre microservicos:

1. Sincrono (request-response):
   Service A --HTTP/gRPC--> Service B --> Response
   Simples, mas cria acoplamento temporal

2. Assincrono (event-driven):
   Service A --publish--> [Message Broker] --consume--> Service B
   (RabbitMQ, Kafka, NATS)
   Desacoplado, mas mais complexo

3. Saga pattern (transacoes distribuidas):
   S1 --ok--> S2 --ok--> S3
   S1 <--compensate-- S2 <--fail-- S3
   (se um passo falha, compensa os anteriores)

Comparação de protocolos síncronos:
  REST/HTTP:  Texto (JSON), simples, amplamente suportado
  gRPC:       Binário (protobuf), tipado, streaming, mais eficiente
  GraphQL:    Query flexível, cliente pede exatamente o que precisa

Teorema CAP:

        Consistency (C)
           /\
          /  \
         /    \
        / CP   \ CA
       /________\
  Partition    Availability
  tolerance(P)    (A)

  C (Consistência):  Todos os nodes veem os mesmos dados ao mesmo tempo
  A (Disponibilidade): Toda request recebe uma resposta (mesmo se dados stale)
  P (Tolerância a partição): Sistema funciona mesmo com falhas de rede

  Em redes reais, partições ACONTECEM → P é obrigatório
  → Escolha real: CP ou AP

  CP (Consistência + Partição): PostgreSQL, ZooKeeper
     Se há partição → recusa requests até sincronizar
  AP (Disponibilidade + Partição): Cassandra, DynamoDB
     Se há partição → serve dados possivelmente desatualizados

Modelos de consistência (do mais forte ao mais fraco):
  Strong consistency:     Leitura sempre retorna o valor mais recente
  Linearizability:        Operações parecem atômicas e ordenadas
  Sequential consistency: Operações de cada cliente são ordenadas
  Causal consistency:     Respeita relações de causa-efeito
  Eventual consistency:   Eventualmente todos os nodes convergem

Algoritmo de consenso Raft (usado por etcd, Consul, CockroachDB):

  1. Eleição de líder (leader election)
     - Nodes começam como followers
     - Se follower não recebe heartbeat → vira candidate
     - Candidate pede votos → maioria → vira leader

  2. Replicação de log
     Leader                 Follower A         Follower B
       |                       |                   |
       |---AppendEntries------>|                   |
       |---AppendEntries------------------------------->|
       |                       |                   |
       |<--ACK-----------------|                   |
       |<--ACK-----------------------------------------|
       |                       |                   |
       | (maioria confirmou → commit)              |
       |---Commit notify------>|                   |
       |---Commit notify------------------------------->|

  3. Se leader falha → nova eleição (timeout-based)

Quorum: N nodes, precisa de (N/2 + 1) para commit
  3 nodes: quorum = 2 (tolera 1 falha)
  5 nodes: quorum = 3 (tolera 2 falhas)

harness.os mesh = service mesh para agentes AI

Conceito de rede distribuída    harness.os equivalente
──────────────────────────     ──────────────────────────────
Microserviço                   Harness instance (marco.ai, build.ai)
Sidecar proxy                  MCP server (intercepta tool calls)
mTLS                           JWT auth entre nodes
Service discovery              schema_reference + project table
Load balancing                 Agent orchestrator (concern routing)
Circuit breaker                Token budget / error threshold
Observability                  claude_session_events table
CDN edge cache                 Prompt cache (tokens reutilizados)
Eventual consistency           Nodes consultam DB sob demanda

Topologia do mesh harness.os:

  ┌─────────────┐
  │  marco.ai   │ (personal harness)
  │  [MCP srv]  │
  └──────┬──────┘
         │
    ┌────┴────┐
    │ [Neon]  │  (shared database = shared state)
    │ purple  │
    │  cell   │
    └────┬────┘
         │
  ┌──────┴──────┐
  │  build.ai   │  (build harness)
  │  [MCP srv]  │
  └──────┬──────┘
         │
  ┌──────┴──────┐
  │ cortex.ai   │  (product harness)
  │  [MCP srv]  │
  └─────────────┘

Modelo de consistência do harness.os:
  Hoje: Strong consistency via PostgreSQL (single writer, CP)
  Trade-off: todas as reads/writes vão ao mesmo DB (gargalo potencial)
  Evolução: eventual consistency com replicação local por node