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. What you really want is for messages to flow between the two worlds without forcing either to change.
On-prem brokerOne messaging platform with its own protocol, format, and addressing — legacy apps depend on it and it isn't going away.- Cloud topicA different messaging platform the new services use. It speaks a different dialect entirely, so messages can't simply cross over.
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. The diagram below shows a message leaving the first system, passing through the bridge, and arriving on the second.
- System A brokerOne messaging platform with its own protocol and format — the bridge looks like an ordinary consumer here.
- Messaging bridgeReceives from A, translates protocol, headers, and payload, then republishes onto B. Thin, stateless, transparent.
- System B topicA different messaging platform — the bridge looks like an ordinary producer here, so both ends stay decoupled.
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 — a crash there can drop or duplicate it. Design the bridge so it only acknowledges the source after the destination has safely accepted the message, and make the relay idempotent so a retry can't deliver the same message twice.
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.