Message Bus

A shared messaging backbone where ERP, WMS, portal, TMS, analytics lake and partner-facing EDI hub all plug in. The pattern that takes the integration graph from N² spaghetti links to 2N organised connections.

Problem

A typical enterprise has 10 to 20 applications that must exchange messages: ERP, warehouse (WMS), transport (TMS), CRM, accounting, supplier portal, analytics lake, plus the EDI hub to partners. If every needing pair talks point-to-point, you end up with N(N-1)/2 connections — ~190 for 20 apps. Each with its format, protocol, retries, errors. The graph becomes unmanageable, each change breaks several branches. A shared backbone is needed.

Forces

• N² coupling reduction. Each application plugs into the bus only (1 link), not into all others.
• Pivot format. The bus enforces its envelope and canonical types; each app translates once.
• Central routing. Who sees what is declared in the bus, not in the apps.
• Latent single point of failure. The bus must be HA / clustered; its outage freezes the whole ecosystem.
• Evolution bottleneck. Changing the canonical format impacts all subscribers. Enforce strict versioning.

Solution

EIP §137 (Hohpe & Woolf, 2003) defines the Message Bus as the combination of three elements: (a) a shared messaging infrastructure (broker / cluster), (b) a shared canonical schema defining the envelope and accepted types (see Canonical model), (c) a set of named channels with routing rules. Any plugging application must accept these three constraints: speak the canonical, use the broker, register in the channel catalogue.

Without bus (N²)                With bus (2N)
   ────────────────                ──────────────

   ERP ──── WMS                    ERP─┐
    \\     /                          │
     \\   /                       WMS ─┤
      \\ /        ┌────────────┐      │
       X         │   message  │       │
      / \\        │    bus     │      │
     /   \\        └────────────┘     │
    /     \\                          │
   TMS ──── PORTAL                TMS ─┤
   POS ──── FINANCE              POS ─┤
                                FIN ─┤
                              PORTAL ─┘

   shared envelope + canonical types + routing rules

EDI implementation

In an EDI context, the bus is the heart of the integration hub. Three typical roles:

• Internal event bus. Kafka topic / Service Bus topic / RabbitMQ exchange broadcasting EDI message status (received, validated, translated, delivered). Each app subscribes to what it needs.
• Canonical payload bus. Topics edi.canonical.orders.in, edi.canonical.invoic.out; on these topics flow messages in canonical JSON, independent of their original format (EDIFACT, X12, UBL, cXML).
• Cross-cutting notification bus. Topic edi.alerts.partner.down warning every app that a partner is down; the portal shows a banner, the retry scheduler pauses, analytics annotates.

# Canonical envelope shared across the bus
{
  "messageId": "01HVF8K3X1ABCDE0123456789",
  "messageType": "INVOIC",
  "schemaVersion": "1.4.0",
  "occurredAt": "2026-05-14T12:00:00Z",
  "source": "edi-hub.inbound.peppol",
  "destinations": ["erp.finance", "portal.supplier", "lake.analytics"],
  "tenantId": "ediverse-prod",
  "correlationId": "PO-12345",
  "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "payload": {
    "issuer": { "gln": "5798000000122", "name": "Acme SAS" },
    "buyer":  { "gln": "7300010000001", "name": "BuyMart" },
    "totals": { "net": 36000, "tax": 7200, "gross": 43200, "currency": "EUR" }
  }
}

Reading: the bus's canonical envelope carries cross-cutting fields (messageId, type, version, source, destinations, trace); the payload is typed by messageType + schemaVersion. Any bus consumer can read the envelope; based on messageType it decides whether it has a parser for the payload.

ESB vs. Message Bus

The ESB term (Enterprise Service Bus, popularised by Chappell, 2004) adds to the Message Bus a layer of transformation and routing inside the bus itself. Modern practice (microservices + cloud, ~2015+) keeps the bus thin (the broker) and moves transformation into separate Translators in a pipes-and-filters pipeline. That is the "smart endpoints, dumb pipes" philosophy (Fowler, 2014).

Anti-patterns

• Bus without canonical. Plugging in a bus but letting each app push its own proprietary format = coupling preserved, only the queue centralised. The canonical is mandatory.
• Business logic inside the bus. Replays the worst ESB excesses of the 2000s: business rules embedded in bus routing configurations, unmovable in case of migration. Keep the bus thin.
• Single-tenant bus only. For a SaaS operator, not multi-tenanting the bus exposes leak and isolation risks. Think tenantId in the envelope or separate brokers.
• No HA. The bus is the single point of failure by design. At least a 3-node cluster, ideally multi-AZ.

Related patterns

• Message Channel — the bus is an assembly of named channels.
• Canonical model — the contractual basis of the bus.
• Message Router — the central router of the bus.
• Pipes and Filters — how to structure processing above the bus.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, Message Bus (§137). enterpriseintegrationpatterns.com — Message Bus
• Chappell D. — Enterprise Service Bus, O'Reilly, 2004. The ESB extension of the bus concept with transformation and orchestration embedded.
• Fowler M. — Microservices, "Smart endpoints and dumb pipes", martinfowler.com, 2014. martinfowler.com — Microservices
• Newman S. — Building Microservices, O'Reilly, 2nd ed. 2021. In-depth discussion of message bus vs. choreography vs. orchestration.