Pular para o conteúdo

apps/data-patterns/messaging-bridge

096 · Dados & Persistência · ≈ 6 min de estudo

Messaging Bridge

Liga dois sistemas de mensageria que não se conhecem: o bridge consome de um broker, traduz o formato e publica no outro. O acoplamento entre o formato legado e o canônico fica num único lugar, e nenhum consumidor moderno precisa aprender o vocabulário do mainframe. Use em migração gradual de broker ou para integrar um legado a uma plataforma nova.

passos
6
arquivos
9
testes
2
tecnologias
6
Infraestrutura realTypeScriptBunElysiaRabbitMQKafkaDocker
Baixar cartão

Cenário

O core bancário em mainframe exporta toda noite as liquidações para uma fila RabbitMQ, no layout COBOL (ACCT, VLR em centavos, DT como YYYYMMDD, STA com uma letra). A plataforma de analytics nova só lê Kafka e só entende o evento canônico. O bridge faz a ponte sem que nenhum dos dois lados mude.

Planta

Sequência
7/7
registro ACCT, VLR, DT, STA, TXID1entrega (prefetch baixo)2traduz para o formato canônico3publica com chave accountId, acks de todas as réplicas4confirmado5ack6evento canônico7registro ilegível: nack sem requeue, vai para a DLQKafka recusou: nack com requeue, nada se perdeMainframeRabbitMQ settlement.legacy.qBridgeKafka settlement.events.v1Analytics
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Liga RabbitMQ e Kafka nos dois sentidos.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    O bridge consome settlement.legacy.q com prefetch baixo, para várias instâncias dividirem a carga

  2. 02

    settlementEventTranslate valida o registro e traduz para o evento canônico — é o único ponto que conhece os dois formatos

  3. 03

    Publica em settlement.events.v1 com a conta como chave (ordem por conta na partição) e acks: -1

  4. 04

    Só depois da confirmação do Kafka dá ack no RabbitMQ; queda entre os dois reentrega, e o consumidor deduplica pelo transaction-id

  5. 05

    Registro ilegível vai direto para settlement.legacy.dlq; Kafka indisponível devolve a mensagem à fila após uma pausa

  6. 06

    /metrics expõe encaminhadas, mortas e reenfileiradas — o bridge é ponto único de falha

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Formato legado não vaza para o lado moderno

  • Migração de broker sem big bang

  • Tradução testável sem infraestrutura

Custos

  • Mais um processo no caminho: ponto único de falha

  • Entrega at-least-once: duplicata possível no destino

  • Latência de um salto extra

apps/data-patterns/messaging-bridge

9 arquivos

./

  • docker-compose.ymlinfraRabbitMQ (legado) e Kafka (moderno)

src/

  • translate_settlement.tsFormatos legado e canônico e a tradução
  • bridge_settlement.tsConsumo, publicação confirmada, ack, DLQ, requeue e métricas
  • topology_bridge.tsFila, DLX e DLQ no RabbitMQ; tópico no Kafka
  • config_bridge.tsVariáveis de ambiente validadas no boot
  • demo.tsdemoLote do mainframe atravessando o bridge
  • translate_settlement.test.tstesteTradução, status, data e recusa sem broker
  • bridge_settlement.test.tstesteEncaminhamento, DLQ e retenção com Kafka fora contra os dois brokers reais

src/producer_mainframe.ts / src/

  • consumer_analytics.tsOs dois lados que não se conhecem

Executar · com Docker

  1. docker compose up -d --wait# sobe RabbitMQ · Kafka
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real

Bridge contínuo: bun run bridge.

Requisitos
BunDocker
Sobe junto
RabbitMQKafka

Por que se relacionam

Teste rápido

Qual destes combina com Messaging Bridge?

Próximo projeto · Dados & PersistênciaData Access Styles: Active Record vs. Data Mapper
Esc

↑ ↓ navegarEnter abrir191 resultados