Messaging Bridge

Picture two offices that each have their own internal mail system — one uses pneumatic tubes, the other uses a fleet of bike couriers. Neither wants to throw out its setup, but they need to send each other memos. So you hire one person to sit between them: they pull a capsule out of the tube, repackage the note into a courier satchel, and hand it off. Each office keeps working exactly as it always did.

A messaging bridge is that person. It sits between two messaging systems and ferries messages across, translating as it goes, so neither system has to learn the other's habits.

The problem

Real systems rarely run on a single messaging platform. You might have an on-premises broker that legacy apps depend on, plus a cloud messaging service your new services use. Or two divisions, each standardized on a different queue technology after a merger. The protocols differ, the message formats differ, even the way you address a destination differs.

You could rewrite one side to match the other — but that's expensive, risky, and often impossible when one end is a vendor product you don't control. The tempting shortcut is a dual write: patch the producer to send every message to both systems. Step through it below, and when the shortcut goes in, predict what happens the first time one of the two writes fails.

Two messaging systems, and the tempting dual write

On-premises, the puts each order on a legacy queue, , and reads it. In the cloud, the new service listens on the for orders.created, and hears nothing.

1 / 4

Read all steps as text

Two worlds. On-premises, the order app puts each order on a legacy queue, ORDERS.OUT, and Billing reads it. In the cloud, the new Shipping service listens on the event bus for orders.created, and hears nothing.
No common ground. Nothing carries orders across, and simply copying bytes wouldn't work either: the two sides differ in protocol, message format and naming.
Dual write. A quick fix: patch the order app to publish every order to both systems. Order 1043 reaches Billing and Shipping.Question: Order 1044: the legacy write succeeds, but the cloud write times out. What happens? Answer: Billing gets order 1044; Shipping never does. Nothing ties two brokers into one transaction. One write landed, the other didn't, and unless the app remembers to retry (and doesn't crash first), the bus never sees 1044.
Out of sync. Billing charges for order 1044, but Shipping never ships it. A dual write can always half-succeed, and you had to patch vendor code just to try.

What you really want is for messages to flow between the two worlds without forcing either to change, and without asking one producer to keep two brokers in step.

How it works

The bridge subscribes to messages on one system and republishes them onto the other. In between, it does the translation work: it speaks the first system's protocol to receive a message, converts the payload and headers into the shape the second system expects, then speaks the second system's protocol to deliver it. Often it runs in both directions.

Crucially, neither end knows the bridge exists as anything special — to the source it looks like an ordinary consumer, and to the destination it looks like an ordinary producer. That keeps both systems fully decoupled, the same loose coupling you get from pub/sub within a single broker, now extended across two of them.

Step through one order crossing the bridge and watch its fields change shape. Then the cloud side goes down: predict when the bridge should acknowledge the legacy queue, and flip between acking on receipt and after publish to see why the order of those two steps decides whether an order can vanish.

Consume, translate, publish, and only then acknowledge

To the is just another consumer. It takes order 1042, still in the legacy format.

1 / 6

Read all steps as text

Consume. To ORDERS.OUT the bridge is just another consumer. It takes order 1042, still in the legacy format.
Translate. The bridge applies its mapping: ORD_NO becomes orderId, the text 003 becomes the number 3, and the queue name becomes the orders.created topic. Neither side has to change.
Publish, then ack. It publishes the event to the event bus. Only when the bus confirms does it ack ORDERS.OUT, which deletes 1042 from the legacy queue. Shipping has its order.
Bus down. The bridge consumes and translates order 1043, but the event bus is down and the publish fails. It keeps retrying while new orders queue up behind it.Question: When should the bridge ack 1043 on ORDERS.OUT? Answer: Only after the bus accepts it; until then, keep retrying. Until the bus confirms, the copy in ORDERS.OUT is the only safe one. Ack early, and anything that stops the bridge takes the order with it.
Restart. A deploy restarts the bridge while the bus is still down. 1043 was never acked, so ORDERS.OUT hands it out again. Nothing is lost: the legacy queue is the buffer.
Bus back. The bus recovers. The bridge publishes 1043, 1044 and 1045, acking each only after the bus confirms, and Shipping has every order. If an ack ever goes missing and 1043 comes round twice, the event keeps its order id, so Shipping skips the repeat.

Tip

Mind the delivery guarantees on both sides. A message that's been received from system A but not yet confirmed onto system B is the danger zone. Acknowledge the source only after the destination has safely accepted the message, and accept that this means an occasional duplicate: if the ack itself gets lost, the source delivers the message again. Carry the source message's id on every event so the destination can recognize a repeat and skip it — many brokers, Azure Service Bus among them, can drop duplicate message ids for you, and idempotent consumers handle the rest.

Check yourself

Your bridge acks each legacy message as soon as it reads it, then publishes to the cloud. During a cloud outage the bridge is redeployed. What happens to the messages it was holding?

Keeping the bridge healthy

A bridge is small, but everything downstream depends on it, so treat it like production infrastructure. Watch the backlog on the source side: when the destination is down, messages pile up there, which is exactly what you want, as long as someone notices before the source runs out of space. Watch the lag between a message arriving and being republished. And version the mapping: when either side adds or renames a field, the translation has to change with it, ideally before the first message in the new shape arrives.

Watch out

Decide what happens to a message the bridge can't translate. One malformed record — a missing field, a code the mapping has never seen — fails on every retry. Retrying it forever blocks every message queued behind it; dropping it silently loses data. Move it to a dead-letter queue, alert someone, and keep the line moving.

When to use it

A messaging bridge earns its place whenever you need two incompatible messaging systems to interoperate but can't (or won't) migrate either one — connecting on-prem to cloud during a phased move, integrating after an acquisition, or letting a modern event-driven system tap into events from a legacy broker.

It's not the right tool if both ends already share a platform — then you just publish and subscribe directly. And resist the urge to pile business rules into the bridge; once it starts making decisions about message content, it stops being a transparent relay and becomes a fragile hub everything depends on. Keep it thin, keep it boring, and keep it focused on translation.

Check yourself

After a network blip, Shipping receives order 1043 twice from your bridge, which acks the legacy queue only after publishing. What's the best fix?

Messaging Bridge

The problem

How it works

Keeping the bridge healthy

When to use it

Key takeaways

Keep going