Integration Patterns & Styles

An integration pattern is the basic “shape” two or more systems connect in — the shape you pick determines how painful the tenth connection will be, not just the first.

At a glance

• What it is: A small catalog of ways systems can be wired together: point-to-point (direct calls), hub-and-spoke (one central router), ESB (Enterprise Service Bus — a shared bus that also translates/transforms messages), API-led (layered APIs behind a gateway), and event-driven (systems react to events instead of being called directly).
• Why it matters: The pattern chosen for the first connection quietly becomes the default for every connection after it — and point-to-point, the easiest pattern to start with, is also the one that scales worst.
• For developers: before writing a new client call to another system, check what pattern the rest of the landscape already uses — adding one more direct call to a system that’s meant to go through a gateway is how “temporary” integrations become permanent technical debt.
• When to use it: Whenever a new system needs to exchange data or trigger behavior in another system — the question is never “should we integrate,” it’s “which shape.”
• When not to use it: Don’t force every integration into one pattern — most real landscapes mix API-led connections for request/response needs with event-driven ones for asynchronous notifications.
• Prerequisites: A basic understanding of Integration Architecture.

Mental model

graph TD
    subgraph "Point-to-point (N systems = up to N² connections)"
    A1[System A] --> B1[System B]
    A1 --> C1[System C]
    B1 --> C1
    B1 --> D1[System D]
    C1 --> D1
    end

graph TD
    subgraph "Hub-and-spoke / API-led (N systems = N connections to the hub)"
    A2[System A] --> H[Hub / Gateway]
    B2[System B] --> H
    C2[System C] --> H
    D2[System D] --> H
    end

Point-to-point connections grow roughly with the square of the number of systems involved — fine for two or three systems, unmanageable past six or seven. Routing through a shared hub, bus, or gateway keeps the connection count linear instead.

Step-by-step walkthrough

1. Count how many systems need to exchange data or trigger each other today, and how many are likely in 12–24 months.
2. Classify each interaction as request/response (needs an answer now) or fire-and-forget (a notification that something happened).
3. For request/response interactions across more than a couple of systems, default to API-led (gateway + layered APIs) over point-to-point.
4. For fire-and-forget interactions, default to event-driven (a broker) over point-to-point.
5. Document the chosen pattern so the next team adding a connection follows it instead of picking their own.

Worked example

A checkout system’s Cart, Pricing, and Payment modules each call three different partner systems (a tax service, a fraud-check service, and a loyalty-points service) directly, with duplicated retry logic and no shared visibility into partner outages.

• Input: nine direct point-to-point calls scattered across three modules, each with its own timeout and retry settings.
• Process: recognize the point-to-point pattern is the root cause, not the individual calls — the fix is a pattern change, not a bug fix. Choose API-led as the target pattern since all nine interactions are request/response.
• Output: a decision to route all partner calls through a gateway, detailed in API-Led Connectivity, which shows how the layering actually gets built. On Azure, that gateway is Azure API Management, giving one place to apply shared timeout/retry policy instead of three copies of the same logic.

Common use cases

Use case	Pattern to reach for	Notes
Two systems, one integration, unlikely to grow	Point-to-point	Simple is fine at small scale — don’t over-engineer a single connection
Many systems calling each other for request/response	API-led (gateway + layered APIs)	See API-Led Connectivity
Systems reacting to “something happened” elsewhere	Event-driven (broker)	See Messaging & Event Brokers
Legacy systems with heavy format translation needs	ESB	Still common in older landscapes; increasingly replaced by API gateways + iPaaS (see Integration Platforms & Middleware)

Advanced details

• Pattern coexistence: mature landscapes typically run API-led and event-driven side by side — the pattern choice is per-interaction, not landscape-wide.
• ESB vs. API-led: an ESB centralizes both routing and transformation logic in one team-owned bus; API-led connectivity spreads ownership across system/process/experience API layers, each with a clearer owner.
• Migration risk: retrofitting a pattern onto an existing point-to-point landscape is a gradual strangler-pattern migration, not a big-bang rewrite — replace one connection at a time behind the new gateway or broker.
• These are named patterns from Enterprise Integration Patterns (Hohpe & Woolf), the standard pattern catalog for messaging-based integration: hub-and-spoke is a Message Router, a topic is a Publish-Subscribe Channel, a queue is a Point-to-Point Channel, and a system API’s job of hiding a backend’s quirky format is a Message Translator. Naming the actual EIP pattern makes a design discussion precise instead of reinventing informal vocabulary for a solved problem.

Quick reference

Term	Meaning
Point-to-point	A direct connection from one system straight to another
Hub-and-spoke	All systems connect to one central router instead of each other
ESB	Enterprise Service Bus — a shared bus that also handles message transformation
API-led connectivity	Layered APIs (system/process/experience) behind a gateway
Event-driven	Systems react to published events instead of being called directly
Enterprise Integration Patterns (EIP)	Hohpe & Woolf’s standard catalog of messaging-integration patterns (Message Router, Message Translator, Publish-Subscribe Channel, and more)

Troubleshooting

Symptom	Likely cause	Fix
Every new integration takes longer than the last	Point-to-point connections growing quadratically	Introduce a gateway or broker and route new connections through it
No one knows which systems call which	No central inventory of point-to-point links	Route through a hub so the hub’s config becomes the inventory
Partner outage takes down multiple unrelated features	Direct calls with no isolation	Move to API-led or event-driven so a gateway/broker can isolate the failure — see Resilience & Error Handling in Integration

Check your understanding

• Why does point-to-point integration get worse faster than hub-and-spoke as the number of systems grows?
• Take an integration you know of — is it request/response or fire-and-forget, and does its current pattern match that need?

Related pages

Part of Introduction to Integration Architecture. See also API-Led Connectivity and Messaging & Event Brokers for the two most common patterns in practice, and the Glossary for term definitions.