MÓDULO 1.5 🌐 T1 Fundamentos

🌐 Comunicação entre Sistemas

REST, GraphQL, gRPC, mensageria — como sistemas conversam

7 Tópicos 30 min Básico Teoria
1

🌍 REST APIs

~83% das APIs públicas

O padrão que domina a web. A API do GitHub é um exemplo clássico de REST bem implementada — cada recurso (/repos, /issues, /pulls) é um endpoint previsível e intuitivo.

📚 Conceito
  • Resources: Tudo é um recurso identificado por URL — /api/users/42
  • Verbs HTTP: GET (ler), POST (criar), PUT (atualizar total), PATCH (atualizar parcial), DELETE (remover)
  • Status Codes: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Error
  • Stateless: Cada requisição contém tudo que o servidor precisa — sem estado entre chamadas
📊 Dados de Adoção
  • 83% das APIs públicas são REST (Postman State of APIs)
  • JSON domina: 95%+ das respostas REST usam JSON
  • OpenAPI/Swagger é o padrão de documentação — usado por 70%+ das empresas
  • HATEOAS é o nível máximo de maturidade REST (Richardson Maturity Level 3), mas raramente implementado

✅ Boas Práticas

  • Usar substantivos nos endpoints: /users em vez de /getUsers
  • Versionar a API: /api/v1/users
  • Paginação em listagens: ?page=2&limit=20
  • Usar status codes corretos para cada situação

❌ Anti-patterns

  • Verbos na URL: /api/deleteUser/42
  • Retornar 200 para tudo com erro no body
  • Endpoints que fazem coisas demais (God endpoints)
  • Ignorar idempotência: PUT e DELETE devem ser idempotentes
2

🔮 GraphQL

Facebook reduziu dados mobile 40%

Criado pelo Facebook em 2012 e open-source desde 2015. O app do Facebook carregava 15+ endpoints REST para montar o feed — com GraphQL, uma única query retorna exatamente os dados necessários.

📚 Conceito
  • Schema: Contrato tipado que define todos os tipos, queries e mutations disponíveis
  • Queries: Cliente pede exatamente os campos que precisa — sem over-fetching
  • Mutations: Operações de escrita (criar, atualizar, deletar) com input tipado
  • Resolvers: Funções que buscam os dados para cada campo do schema

✅ Quando Usar

  • Apps mobile com bandwidth limitado
  • Múltiplos frontends com necessidades diferentes
  • Dados altamente relacionais e aninhados

❌ Quando Não Usar

  • APIs simples com poucos endpoints
  • Quando cache HTTP nativo é crítico
  • File upload como operação principal
💡 Dica Prática

Cuidado com o N+1 problem: uma query GraphQL pode gerar centenas de queries SQL sem você perceber. Use DataLoader para batch requests ao banco. O Shopify enfrentou isso e criou seu próprio DataLoader em Ruby — reduziu queries de banco em 90% em alguns resolvers.

3

⚡ gRPC

Google: 10x mais rápido que REST+JSON

Framework RPC do Google usando Protocol Buffers e HTTP/2. Fortemente tipado, com geração automática de código em 12+ linguagens. Ideal para comunicação interna entre microsserviços.

📚 Conceito
  • Protobuf: Serialização binária — 3-10x menor que JSON, parsing muito mais rápido
  • HTTP/2: Multiplexing, header compression, streaming bidirecional nativo
  • Strongly Typed: Contratos .proto geram código client/server automaticamente
  • 4 Modos: Unary, Server streaming, Client streaming, Bidirectional streaming
📊 Comparação de Performance
Tamanho payload (user object)
JSON: ~82 bytes Protobuf: ~28 bytes
Serialização
JSON: ~3ms Protobuf: ~0.4ms
Latência média
REST: ~10ms gRPC: ~1ms
💡 Dica Prática

gRPC é ideal para service-to-service. Não tente usá-lo direto no browser (sem gRPC-Web proxy). Para APIs públicas, mantenha REST ou GraphQL na borda e use gRPC internamente. O Google, Netflix e Spotify fazem exatamente isso: REST para clientes externos, gRPC entre microsserviços.

4

📨 Mensageria Assíncrona

Mercado Livre: 1M+ transações/dia via Kafka

Comunicação via mensagens em filas ou tópicos. O produtor não espera resposta — publica um evento e segue. O checkout do Mercado Livre não espera o email de confirmação; publica um evento e segue.

📚 Conceito
  • Queue (Fila): Uma mensagem vai para um único consumidor — SQS, RabbitMQ. Ideal para tarefas
  • Topic (Tópico): Uma mensagem vai para todos os assinantes — Kafka, SNS. Ideal para eventos
  • At-least-once: Garante entrega, mas pode duplicar — exige idempotência no consumidor
  • Exactly-once: Ideal mas difícil — Kafka Transactions oferece semelhante
🕐 Fluxo de Evento
1
Produtor publica evento

checkout.completed → Kafka topic

2
Broker persiste e distribui

Kafka armazena com offset, replica para consumer groups

3
Consumidores processam

Email service, Analytics, Inventário — cada um no seu ritmo

4
ACK confirma processamento

Offset avança, mensagem processada com sucesso

⚠️ Alerta: Dead Letter Queue (DLQ)

Mensagens que falham repetidamente vão para a DLQ em vez de bloquear a fila. Sem DLQ, uma mensagem “envenenada” pode travar todo o pipeline. Configure: máximo de retries (ex: 3), delay entre retries (exponential backoff), alerta quando DLQ recebe mensagens. Monitore a DLQ — mensagens lá significam bugs ou dados inesperados que precisam de investigação.

5

🔄 Webhooks

Stripe, GitHub, Slack

HTTP callbacks — um sistema notifica outro quando algo acontece. Quando um pagamento é aprovado no Stripe, seu sistema recebe um POST instantâneo em vez de ficar polling a cada 5 segundos.

📚 Conceito: HTTP Callbacks
  • Registro: Você cadastra uma URL no provedor (ex: https://meuapp.com/webhooks/stripe)
  • Trigger: Quando o evento ocorre, o provedor faz POST na sua URL com payload JSON
  • Resposta: Seu servidor retorna 200 OK para confirmar recebimento
  • Retry: Se falhar, o provedor tenta novamente (geralmente 3-5x com backoff)
💡 Segurança e Idempotência
  • HMAC Signature: Sempre valide a assinatura do webhook — confirma que veio do provedor real, não de um atacante
  • Idempotency Key: Webhooks podem ser entregues mais de uma vez. Use o event ID para deduplicar
  • Responda rápido: Retorne 200 imediatamente e processe async. Timeout do Stripe: 20s
  • Log tudo: Guarde payload + headers para debugging

✅ Fazer

  • Validar assinatura HMAC antes de processar
  • Usar fila interna para processar (recebe → enfileira → 200 OK)
  • Implementar idempotência com event ID
  • Ter endpoint de health check para o provedor

❌ Evitar

  • Processar tudo na hora do request (timeout!)
  • Ignorar validação de assinatura (vuln de segurança)
  • Assumir entrega única (webhooks podem duplicar)
  • Expor endpoint sem HTTPS
6

🌊 WebSockets e SSE

Figma: colaboração <50ms

Quando polling não basta. O Figma usa WebSockets para sincronizar cursores e mudanças em tempo real entre todos os colaboradores com latência abaixo de 50ms.

📚 Full-duplex vs Half-duplex
  • WebSocket (Full-duplex): Cliente e servidor enviam dados simultaneamente pela mesma conexão
  • SSE (Half-duplex): Servidor envia dados para o cliente via stream HTTP. Cliente usa requests normais para enviar
  • Handshake: WebSocket faz upgrade de HTTP para protocolo ws://
📊 Use Cases
  • WebSocket: Chat, games, colaboração real-time, trading
  • SSE: Feeds, notificações, dashboards, logs ao vivo
  • Polling: Dados que mudam a cada minuto+, sem necessidade de real-time
💡 SSE como Alternativa Simples

Se você só precisa de server → client, SSE é muito mais simples:

  • ✓ Funciona sobre HTTP normal
  • ✓ Reconnect automático nativo
  • ✓ Funciona com load balancers HTTP
  • ✓ Event IDs para retry sem perda
7

🔀 API Gateway e Service Mesh

Netflix Zuul: 2B+ requests/dia

Sem gateway, cada serviço reimplementa auth, rate limiting e logging. A Netflix usa Zuul como API Gateway — 2 bilhões+ de requests por dia passam por ele antes de chegar aos microsserviços.

📚 Gateway vs Mesh
  • API Gateway (Norte-Sul): Ponto de entrada para tráfego externo. Auth, rate limiting, transformação. Ex: Kong, AWS API Gateway, Zuul
  • Service Mesh (Leste-Oeste): Gerencia comunicação interna entre serviços. mTLS, retry, circuit breaker. Ex: Istio, Linkerd
  • Sidecar Pattern: Mesh injeta proxy ao lado de cada serviço — lógica de rede sem tocar no código
🕐 Quando Adicionar
1
1-3 serviços

Nenhum dos dois. Comunicação direta. KISS.

2
5-15 serviços

API Gateway na borda. Centraliza auth e rate limiting.

3
20-50 serviços

Considere Service Mesh. Observabilidade e segurança interna ficam críticas.

4
50+ serviços

Gateway + Mesh juntos. Netflix, Google, Uber operam neste nível.

✅ Fazer

  • Centralizar cross-cutting concerns no gateway (auth, logs, CORS)
  • Configurar circuit breaker para evitar cascata de falhas
  • Usar health checks e retry com backoff exponencial
  • Monitorar latência adicionada pelo gateway/mesh

❌ Evitar

  • Colocar lógica de negócio no gateway (ele é infraestrutura!)
  • Adotar Service Mesh com 5 serviços (overengineering)
  • Gateway como single point of failure sem redundância
  • Ignorar o overhead de latência do sidecar proxy
🎉

Parabéns! Você completou a Trilha 1 — Fundamentos de Arquitetura

Checklist dos 7 padrões de comunicação que você aprendeu:

✅
REST APIs

Resources, verbs, status codes

✅
GraphQL

Schema, queries, mutations

✅
gRPC

Protobuf, HTTP/2, streaming

✅
Mensageria

Kafka, queues, topics, DLQ

✅
Webhooks

HMAC, idempotency, callbacks

✅
WebSockets e SSE

Real-time, full-duplex, streams

✅
API Gateway e Service Mesh

Norte-sul, leste-oeste, sidecar

📚 Ver todos os módulos da Trilha 1 Avançar para Trilha 2: Estratégias de Decisão 🎯
← Voltar para Trilha Próxima Trilha: Estratégias de Decisão →