‹M03·02Conceitos Fundamentais
01020304050607080910

CAPÍTULO 02

Conceitos Fundamentais

Comunicação síncrona versus assíncrona, Event-Driven Architecture e quando escolher cada abordagem.

Por Thiago Souza7 min de leituraAtualizado em 2026-05

Comunicação Síncrona vs Assíncrona

Síncrona = Telefonema

Você liga. A pessoa atende. Vocês conversam em tempo real. Se a pessoa não atender, você espera tocando. Se a linha cair, vocês param.

Características:

  • Cliente espera a resposta.
  • Acoplamento forte: se o servidor cair, o cliente quebra.
  • Simples de raciocinar.
  • Latência aparece direto pro usuário.

Exemplos: HTTP REST, gRPC, chamada de função em RPC.

Assíncrona = Carta

Você escreve a carta, joga no correio e continua sua vida. A carta vai chegar (em algum momento), e o destinatário vai ler quando puder. A resposta, se vier, chega depois.

Características:

  • Cliente não espera a resposta imediatamente.
  • Acoplamento fraco: se o servidor estiver fora, a mensagem fica esperando.
  • Mais robusta a falhas.
  • Mais difícil de raciocinar (e de debugar).

Exemplos: Kafka, RabbitMQ, AWS SQS, e-mail.

Tabela Comparativa

AspectoSíncrona (HTTP)Assíncrona (Kafka)
Tempo de respostaImediato"Quando der"
AcoplamentoForteFraco
Resiliência a falhaBaixaAlta
ComplexidadeBaixaAlta
ThroughputLimitadoMuito alto
Caso típicoLogin, consulta de saldoNotificações, eventos, ETL
Regra prática: se o usuário precisa da resposta agora na tela, use síncrono. Se algo precisa acontecer eventualmente, use assíncrono.

Event-Driven Architecture (EDA)

Em arquiteturas tradicionais, serviços chamam uns aos outros dizendo "faça isso":

flowchart LR
  P[Pedidos] -->|"crie nota fiscal"| F[Faturamento]
  P -->|"reduza estoque"| E[Estoque]
  P -->|"envie e-mail"| N[Notificações]

O serviço de Pedidos precisa conhecer todos os outros. Se amanhã surgir um novo serviço (ex: pontos de fidelidade), você precisa mexer no serviço de Pedidos. Isso é chamado acoplamento.

Em EDA, o serviço apenas anuncia o que aconteceu:

flowchart LR
  P[Pedidos] -->|"PedidoCriado"| B[[Broker]]
  B --> F[Faturamento]
  B --> S[Estoque]
  B --> N[Notificações]
  B --> Fi["Fidelidade (novo!)"]

O Pedidos não sabe quem está ouvindo. Ele só publica um evento. Quem se importar, escuta. Adicionar um novo serviço é só plugar ele no evento — zero alteração no serviço original.

Analogia: o jornal. O Estado de São Paulo não liga pra cada leitor todo dia. Ele publica o jornal. Quem quiser, assina e lê. Novos leitores aparecem? Ótimo, sem mudar nada na redação.

Conceitos-chave de EDA:

  • Evento: algo que aconteceu no passado (PedidoCriado, PagamentoAprovado). Note o tempo verbal: passado.
  • Producer/Publisher: quem emite o evento.
  • Consumer/Subscriber: quem reage ao evento.
  • Broker: o intermediário que entrega os eventos.