Pular para o conteúdo
thiagoetipadrões

Contatos

apps/messaging-streaming/message-broker

056 · Comunicação & Mensageria · ≈ 6 min de estudo

Message Broker

Intermediário que desacopla quem produz de quem consome: o produtor publica um fato numa exchange com uma routing key e não sabe quem recebe; cada consumidor conhece só a própria fila. O broker guarda a mensagem até alguém consumir e decide, pelos bindings, quem recebe cópia.

passos
6
arquivos
6
teste
1
tecnologias
4
Infraestrutura realTypeScriptBunRabbitMQDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Um banco digital publica os eventos de cada transferência — pedida, liquidada, falhou. A equipe de processamento consome os pedidos, a de notificação avisa o cliente do resultado e a conciliação registra tudo. Nenhuma equipe conhece o produtor nem as outras; se uma estiver fora do ar, as mensagens esperam na fila dela.

Planta

Fluxo
8/8
Produtortransferênciasbank.eventstopic exchangetransfer-processingtransfer.*.requestedcustomer-notificationtransfer.*.settledtransfer.*.failedreconciliationtransfer.#bank.events.dlxbank-events-dlqtransfer.pix.requestednack sem requeuenack sem requeuenack sem requeue
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Intermediário desacopla produtor e consumidor.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

ack+12
nack+6
mandatory+5
prefetch+2
domínio.subtipo.estado+1
  1. 01

    Produtor e consumidores declaram a mesma topologia: exchange topic, filas duráveis com DLX e bindings por padrão

  2. 02

    O produtor publica com routing key domínio.subtipo.estado (transfer.pix.requested), mensagem persistente e canal com confirmação

  3. 03

    mandatory + listener de return: routing key que nenhum binding casa vira erro no produtor, não descarte silencioso

  4. 04

    * casa exatamente uma palavra, # casa zero ou mais — a conciliação recebe todo evento de transferência

  5. 05

    Cada consumidor usa prefetch, faz ack depois do efeito e nack sem requeue para mensagem ilegível, que cai na DLQ

  6. 06

    Redeclarar uma fila com argumentos diferentes é recusado com PRECONDITION_FAILED

apps/messaging-streaming/message-broker

6 arquivos

src/

  • topology_bank.tsExchange, filas com DLX, bindings por padrão e publicação confirmada com mandatory
  • consumer_bank.tsConsumidor de uma fila: prefetch, ack após o efeito, nack para a DLX, parada com drenagem
  • config_bank.tsVariáveis de ambiente validadas no boot
  • topology_bank.test.tstesteIntegração com RabbitMQ real: roteamento por padrão, limite do *, mensagem sem rota, fila que segura até o consumidor subir, DLQ e redeclaração
  • demo.tsdemoProdutor publica sem consumidor no ar; três equipes drenam as próprias filas

./

  • docker.shinfraSobe o RabbitMQ 3 na porta 5672

Executar · com Docker

  1. ./docker.sh up# sobe RabbitMQ
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
RabbitMQ

Relações

Onde ele se encaixa

Mapa
  1. Message Broker
  2. próximo passoMessage Routing
  • Próximo passo1
  • Combina com7
  • Alternativa a2

L10Pipeline de mensagens· estação 1 de 6

início da linhaMessage Routing →

Por que se relacionam

Próximo passo

Combina com

Alternativa a

Tipos de exchange

Exchange Roteia por Use quando
Direct routing key exata destino fixo e conhecido
Topic padrão com * e # roteamento hierárquico por evento — este exemplo
Fanout ignora a routing key todo sistema precisa receber
Headers atributos da mensagem critério multidimensional

Teste rápido

Qual é o próximo passo depois de Message Broker?

Próximo projeto · Comunicação & MensageriaPriority Queue
Esc

↑ ↓ navegarEnter abrir191 resultados