Pular para o conteúdo
thiagoetipadrões

Contatos

apps/patterns/amqp-message-handler

001 · Padrões Fundamentais · ≈ 5 min de estudo

AMQP Message Handler

Consumo robusto de mensagens RabbitMQ: ack só depois do efeito, retry atrasado por filas com TTL, dead-letter queue para falha permanente e deduplicação da reentrega. Use quando um consumer não pode perder nem processar duas vezes a mesma mensagem.

passos
6
arquivos
8
teste
1
tecnologias
5
Infraestrutura realTypeScriptBunRedisRabbitMQDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Liquidação de PIX num banco digital. O PIX-001 falha uma vez por indisponibilidade e é liquidado no retry; o PIX-002 chega duas vezes e é liquidado uma só; o PIX-BLOCKED é bloqueado pela detecção de fraude e vai direto para a DLQ.

Planta

Fluxo
9/9
Publicador (confirm+ mandatory)payments.exchange (topic)payments.queueWorker (prefetch 10)Redis: claim por id do PIXpayments.queue.retry.200/ .400 (TTL)payments.dlxpayments.dlqpublicapayments.transferroteia por payments.#entregaSET NX: já liquidadovira ack sem efeitoack após liquidarfalha transitória:cópia com x-attempt + 1TTL expira e voltapermanente ouretries esgotados:nack sem requeueencaminha
9

9 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Consome AMQP com ack, nack e requeue.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

nack+6
SET NX+3
x-death+3
prefetch+2
payments.dlq+1
  1. 01

    PublicaçãoConfirm channel com mandatory: true e persistent: true — routing key sem binding vira erro, não mensagem perdida

  2. 02

    RoteamentoA topic exchange entrega na fila pelo binding payments.#

  3. 03

    Consumoprefetch limita as mensagens sem ack por worker; o ack só sai depois da liquidação

  4. 04

    IdempotênciaSET NX no Redis com o id do PIX — a reentrega de um PIX liquidado recebe ack sem novo efeito

  5. 05

    Retry atrasadoFalha transitória publica a cópia confirmada numa fila de TTL fixo e só então faz o ack da original

  6. 06

    DLQErro permanente, JSON inválido ou retries esgotados → nack sem requeue, e a DLX leva à payments.dlq com o header x-death

apps/patterns/amqp-message-handler

8 arquivos

src/

  • config_payment.tsLê e valida o ambiente no boot
  • topology_payment.tsExchange, fila, DLX, DLQ e filas de retry
  • publisher_payment.tsPublicação confirmada com mandatory
  • worker_payment.tsConsumo com prefetch, ack, retry e DLQ
  • idempotency_payment.tsClaim do id do PIX no Redis
  • worker_payment.test.tstesteIntegração contra RabbitMQ e Redis reais
  • demo.tsdemoPublica 5 mensagens e mostra ack, duplicata, retry e DLQ

./

  • docker-compose.ymlinfraRabbitMQ com management UI e Redis

Executar · com Docker

  1. docker compose up -d# sobe Redis · RabbitMQ
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário

Filas em tempo real: http://localhost:15672 (guest / guest). Teste de integração: bun run test.

Requisitos
BunDocker
Sobe junto
RedisRabbitMQ

Relações

Onde ele se encaixa

Mapa
  1. AMQP Message Handler
  • Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com AMQP Message Handler?

Próximo projeto · Padrões FundamentaisAsync Request-Reply
Esc

↑ ↓ navegarEnter abrir191 resultados