Distributed Application Architecture Patterns

11.3 Messaging Bridge

This pattern is based on Messaging Bridge defined by Hohpe et al. [4, p. 132, 206] and later by Microsoft [207], and Message Mover by Fehling et al. [15, p. 225, 208].

11.3.1 Context

Two services need to communicate with each other but use incompatible messaging middleware. Linking them without changing (at least one of) the underlying services is preferred.

11.3.2 Solution

Create a new service (or change one of the existing parties) that acts as a bridge between the two brokers. This service receives messages from one broker and forwards them to the other (see fig. 36).

11.3.3 Potential issues

Adding a bridge increases complexity and introduces an additional point of failure and latency to the system.

The two brokers may also have incompatible features that need to be reconciled.

11.3.4 Example

ExampleEshop wants to transition to a newer, more efficient messaging system for its new services. However, this process takes time and switching all services at once is unfeasible. To address this, the eshop deploys a messaging bridge that translates messages between the old and new systems. This allows them to gradually migrate services to the new system without updating the old services. Once all services are migrated, the bridge is removed.

11.3.5 Related patterns

• See Publisher–Subscriber for more information on message middleware (see § 4.2)

• The bridge may need to be scaled out using Competing Consumers (see § 6.1)

• If the systems also have incompatible domains, consider using an Anti-Corruption Layer (see § 11.1)