College Online
0%

Redes Distribuidas

Modulo 5 · Aula 3 ~25 min de leitura Nivel: Avancado

Video da aula estara disponivel em breve

CDN: Content Delivery Networks

Uma CDN replica conteudo em servidores distribuidos geograficamente (edge servers). Quando um usuario acessa o conteudo, ele e servido pelo servidor mais proximo, reduzindo latencia.

Diagrama 
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

Load Balancing

Load balancers distribuem trafego entre multiplas instancias de um servico. Estrategias comuns:

Referencia 
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

Service Mesh

Um service mesh e uma camada de infraestrutura dedicada que gerencia comunicacao entre microservicos. O padrao mais comum e o sidecar proxy: cada servico tem um proxy local que intercepta todo trafego de rede.

Diagrama 
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

Microservices networking

Diagrama 
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)

No harness.os

Diagrama 
harness.os mesh = service mesh para agentes AI

Conceito de service mesh       harness.os equivalente
──────────────────────────     ──────────────────────────────
Microservico                   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
Circuit breaker                Token budget / error threshold
Observability                  claude_session_events table

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]  │
  └─────────────┘

Eventual consistency: todos os nodes compartilham
o Neon DB, mas cada um tem seu proprio cache local.
Mudancas no DB propagam para todos na proxima query.
*
Neon como "shared bus" No harness.os, o Neon Postgres funciona como um "barramento compartilhado" — todos os nodes leem e escrevem no mesmo banco. Isso simplifica a consistencia (strong consistency via PostgreSQL), mas cria um ponto unico de falha. Em uma evolucao futura, cada node poderia ter um banco local com replicacao eventual.

Resumo

Exercicio pratico

Projete uma estrategia de load balancing para o harness.os quando multiplos agentes compartilham o mesmo MCP server.

  1. Qual algoritmo de load balancing e mais adequado? (round-robin? least connections?)
  2. Como implementar rate limiting por agente?
  3. O que acontece quando o MCP server atinge capacidade maxima? (backpressure)
  4. Projete um circuit breaker: apos N falhas, desabilite o agente por T segundos

Verifique seu entendimento

Qual e a principal funcao do sidecar proxy em um service mesh?

  • Armazenar dados do servico localmente
  • Interceptar e gerenciar toda comunicacao de rede do servico (mTLS, retries, observability)
  • Compilar e deployar o servico automaticamente
  • Gerenciar a base de dados do servico