Visão geral

São 09:59:58 e um show em estádio está prestes a abrir as vendas no BoxOffice. Às 10:00, dois milhões de fãs apertam "Comprar" para sessenta mil lugares. Por trás desse botão, a primeira versão do BoxOffice faz tudo em uma única requisição síncrona: reserva os lugares, cobra o cartão, envia o e-mail, manda uma notificação push para o celular, atualiza o índice de busca e registra a venda para o analytics. O provedor de e-mail está um pouco lento hoje (800 ms em vez de 80 ms), então cada compra passa a levar um segundo a mais, o serviço order fica sem threads e os fãs que estavam prestes a pagar veem um spinner e depois um erro. Nada estava quebrado — o sistema simplesmente foi ligado de um jeito em que cada passo precisava terminar antes que qualquer usuário recebesse uma resposta.

Esta aula é sobre a outra forma de ligar os serviços: mensagens. Em vez de chamar cada serviço e esperar, um serviço escreve uma mensagem em um broker e segue em frente; quem precisa dela a lê quando puder. Bem feita, a mensageria absorve picos, desacopla times e tira serviços lentos ou com falha do caminho crítico. Feita sem cuidado, perde pedidos, duplica e-mails e esconde falhas em uma fila que ninguém observa. Vamos aprender os dois lados.

Roteiro

1. Esta visão geral — síncrono vs assíncrono, o que um broker oferece (e quanto custa), nivelamento de carga em números, o vocabulário e os quatro componentes de mensageria da paleta.
2. Filas e pub/sub — filas ponto a ponto, consumidores concorrentes, confirmações, backpressure, a sala de espera da flash sale e o fan-out do pub/sub.
3. Kafka e logs de eventos — a abstração de log, partições, chaves e ordenação, consumer groups, replicação, retenção, compactação e dimensionamento de partições.
4. Semântica de entrega — at-most/at-least/exactly-once, consumidores idempotentes, ordenação, retries e dead letter queues, evolução de schema.
5. Padrões — transactional outbox, change data capture, sagas, CQRS e event sourcing, todos aplicados à compra no BoxOffice.
6. Quiz — teste seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Síncrono vs assíncrono

Em uma interação síncrona, quem chama envia uma requisição e espera a resposta antes de continuar — uma chamada HTTP ou gRPC. Em uma interação assíncrona, quem chama entrega uma mensagem a um intermediário (um broker) e continua imediatamente; o receptor processa a mensagem depois, possivelmente muito depois, possivelmente em outro continente.

Compare as duas versões da compra no BoxOffice. O usuário clica em "Comprar"; o serviço order precisa criar o pedido, e outros cinco serviços precisam ficar sabendo dele.

sequenceDiagram
    autonumber
    participant U as Fã
    participant O as order
    participant N as notification
    participant S as search
    participant A as analytics
    U->>+O: POST /orders
    O->>+N: envia e-mail + push
    N-->>-O: ok (800 ms hoje)
    O->>+S: atualiza "lugares restantes"
    S-->>-O: ok
    O->>+A: registra a venda
    A-->>-O: ok
    O-->>-U: 201 Created (depois de todos eles)

sequenceDiagram
    autonumber
    participant U as Fã
    participant O as order
    participant K as Kafka
    participant N as notification
    participant S as search
    participant A as analytics
    U->>+O: POST /orders
    O->>K: publica OrderConfirmed
    O-->>-U: 201 Created
    K-->>N: OrderConfirmed
    K-->>S: OrderConfirmed
    K-->>A: OrderConfirmed

A diferença não é só velocidade. Ela aparece em três números que você já sabe calcular (veja Estimativas):

O que um broker oferece

Um message broker é um servidor que recebe mensagens de produtores, as armazena de forma durável e as entrega a consumidores¹. Colocar um broker entre dois serviços traz quatro propriedades que uma chamada direta não traz:

1. Desacoplamento temporal. Produtor e consumidor não precisam estar no ar ao mesmo tempo. Se o notification está sendo reimplantado, os eventos OrderConfirmed esperam no broker.
2. Nivelamento de carga. O broker é um buffer: produtores podem escrever mais rápido do que os consumidores leem por um tempo, e o backlog escoa depois. Um pico vira uma fila em vez de uma indisponibilidade.
3. Fan-out. Um evento publicado pode ser entregue a muitos consumidores independentes. Adicionar um novo consumidor (detecção de fraude, programa de fidelidade) não mexe no produtor.
4. Escala independente e isolamento de falhas. Cada consumidor escala com a própria carga e falha sozinho. Um pipeline de analytics lento não atrasa os e-mails.

Nada é de graça. O preço da assincronia:

• Consistência eventual. Por um tempo, a página de busca pode ainda mostrar "120 lugares restantes" quando já são 80. O sistema precisa ser projetado (e a interface, redigida) para isso².
• Duplicatas e reordenação. A maioria dos brokers entrega at least once: consumidores vão ver a mesma mensagem duas vezes e precisam ser idempotentes (veja Semântica de entrega).
• Depuração mais difícil. Uma compra agora é uma cadeia de eventos entre tópicos; sem tracing distribuído e métricas de consumer lag, as falhas se escondem em um backlog (veja Observabilidade).
• Mais um sistema crítico. O broker precisa ser replicado, monitorado, atualizado e ter sua capacidade planejada.

Nivelamento de carga em números

A flash sale é o caso clássico de nivelamento de carga. As requisições de compra dos fãs chegam muito mais rápido do que o inventory consegue processar reservas, mas só por alguns minutos. Se o order chamasse o inventory diretamente, o excesso viraria timeouts e erros. Com uma fila no meio, o excesso vira backlog — mensagens esperando — e o único custo é tempo de espera.

A simulação abaixo usa números ilustrativos: 200 requisições/s antes das 10:00, um pico de 6.000 requisições/s por três minutos e depois uma multidão que diminui devagar. Os workers processam 2.000 ou 4.000 requisições/s.

Três coisas para ler no gráfico:

• O backlog cresce na diferença das taxas. Durante o pico ele cresce \(6000 - 2000 = 4000\) mensagens por segundo com o pool menor de workers: em três minutos, \(4000 \times 180 = 720{,}000\) mensagens.
• A espera é o backlog dividido pelo throughput — a Lei de Little de novo (veja Filas): \(720{,}000 / 2000 = 360\) s, seis minutos para o último fã da fila. Dobrar os workers reduz o pico pela metade e o escoa muito mais rápido.
• O backlog só escoa quando as chegadas caem abaixo da capacidade. Se a taxa média de chegada fica acima da capacidade, nenhuma fila salva você: o backlog cresce para sempre. Uma fila absorve picos, não uma falta permanente de capacidade.

O vocabulário

Mensageria tem muitas palavras para coisas parecidas. Estas são as que usamos no curso.

O que vai dentro de um evento

Martin Fowler distingue várias coisas que as pessoas querem dizer com "orientado a eventos"³. Duas delas mudam a forma de projetar o payload:

{ "type": "OrderConfirmed", "eventId": "e-9f2c", "orderId": "o-7731", "occurredAt": "2027-03-14T10:00:07Z" }

{
  "type": "OrderConfirmed", "eventId": "e-9f2c", "orderId": "o-7731",
  "occurredAt": "2027-03-14T10:00:07Z",
  "customer": { "id": "c-12", "email": "ana@example.com", "locale": "pt-BR" },
  "event": { "id": "ev-88", "name": "Stadium Show", "startsAt": "2027-05-01T21:00:00-03:00" },
  "seats": ["B-12", "B-13"], "total": { "amount": 780.00, "currency": "BRL" }
}

Os outros dois significados — event sourcing e CQRS — são padrões de arquitetura tratados em Padrões.

A paleta de mensageria

O System Design Playground tem quatro componentes de mensageria. Não são quatro marcas; são quatro formas de comunicação. O catálogo de componentes tem os detalhes de cada um.

A pergunta decisiva é o que acontece com uma mensagem depois que ela é lida:

• Em uma fila, ler é tirar: a mensagem some quando confirmada. Ótimo para distribuir trabalho.
• Em um log, ler é olhar: a mensagem fica, e cada leitor guarda um marcador. Ótimo para muitos leitores independentes, replay e histórico.

flowchart TD
    q1{"Quem chama precisa da<br/>resposta para continuar?"}
    q1 -->|sim| sync["Chamada síncrona<br/>(REST / gRPC) + timeout"]
    q1 -->|não| q2{"Quantos serviços<br/>precisam reagir?"}
    q2 -->|"exatamente um<br/>(um trabalho a fazer)"| queue["queue<br/>consumidores concorrentes"]
    q2 -->|"muitos, cada um com sua cópia"| q3{"Precisa de replay, ordem<br/>por chave ou alto throughput?"}
    q3 -->|não| pubsub["pubsub<br/>tópico + assinaturas"]
    q3 -->|sim| log["stream / kafka<br/>log particionado"]

Quando não usar assincronia

O mapa de conceitos de mensageria

Toda mensagem percorre o mesmo caminho: um produtor a entrega a um dos quatro componentes de mensageria, e um consumidor a processa depois. O mapa liga cada componente da paleta (verde) aos conceitos desta aula (azul) e às aulas que os continuam:

flowchart LR
    order["app (order)<br/>produtor"]:::comp --> queue["queue"]:::comp
    order --> pubsub["pubsub"]:::comp
    order --> log["stream · kafka"]:::comp
    queue --> worker["worker"]:::comp
    pubsub --> cons["notifications · search ·<br/>analytics"]:::comp
    log --> cons
    order -.- c0["síncrono vs assíncrono, outbox,<br/>sagas, CQRS, event sourcing"]:::tech
    queue -.- c1["consumidores concorrentes, ack,<br/>backpressure, sala de espera"]:::tech
    pubsub -.- c2["fan-out, assinaturas,<br/>push/pull, filtros"]:::tech
    log -.- c3["partições, chaves, offsets,<br/>consumer groups, retenção"]:::tech
    worker -.- c4["pelo menos uma vez, consumidor idempotente,<br/>ordenação, DLQ, schemas"]:::tech
    c3 -.- d1["consenso, KRaft<br/>(aula 3)"]
    c4 -.- d2["retries, SLO de atualidade<br/>(aulas 9 e 10)"]
    c4 -.- d3["consumer lag, tracing<br/>(aula 9)"]
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Relacionados

• Hands-on: Hands-on 7 — Assíncrono: Kafka, transactional outbox no order, consumidor idempotente no notification, DLQ e a fila da sala de espera.
• Exercício: Exercício orientado a eventos — outbox + consumidor idempotente.
• Estudos de caso: Venda de ingressos (flash sale do BoxOffice), Sistema de notificações, Sistema de pagamentos, Chat.
• Aulas: Computação — trabalho assíncrono (workers e schedulers), Observabilidade (consumer lag e tracing entre tópicos), Confiabilidade (retries, backoff, idempotência).

O que quebra em seguida

O e-mail saiu da requisição: no lab 7, uma falha no e-mail não derruba mais nenhum pedido, e a sala de espera só deixa entrar o que o inventory consegue atender. O preço é a visibilidade. Uma compra agora é uma requisição, uma linha no banco, um relay do outbox, um registro no Kafka e um consumidor, em quatro processos e em quatro momentos diferentes: quando um fã diz "paguei e não recebi o e-mail", ninguém consegue dizer onde o pedido parou. E quando o provedor de pagamento fica lento, as médias nos dashboards continuam verdes enquanto os fãs falham no checkout. Seguir um pedido entre serviços, e medir o que os fãs de fato sentem, é a aula 9 — Observabilidade.