Integration architecture patterns are the shapes that keep turning up when an organization connects its systems: direct links between pairs of applications, a central hub that brokers every exchange, a shared bus, a stream of events that any system can subscribe to, or a layered set of APIs. Every estate has one of these shapes, whether anyone chose it or not, and most have several at once. The pattern matters because it decides what a change will cost. Adding a new system, replacing an old one or riding out an outage is cheap in some shapes and ruinous in others – and, usually, nobody sees the difference until years after the decision was made.
In this article, I’ll describe the five patterns that cover nearly all real integration work, when each one is the right choice, how each one tends to fail, and how teams move from one to another without stopping the business. I’ve written it for architects and delivery leads who inherited their estate instead of designing it, which, in my experience, is almost everyone.
Why the pattern matters more than the tool
Conversations about integration architecture have a way of turning into arguments about products – one iPaaS against another, Kafka against a managed queue, a commercial ESB against something open source. The products matter less than people think. You can build any of the patterns below with any of them, and a badly chosen pattern built in an excellent tool is still a badly chosen pattern. A modern integration platform full of direct, undocumented, system-to-system flows is simply point-to-point integration with a nicer user interface.
What the pattern really decides is where knowledge and responsibility live. In some shapes, every system knows about every other system it talks to. In others, a system knows only about a contract, and something else keeps track of who is listening. That distinction – coupling to a partner versus coupling to a contract – runs through everything that follows.
The five patterns
Point-to-point
In a point-to-point architecture, each pair of systems that needs to exchange data is connected directly, usually by one calling the other’s API, reading its database or swapping files with it. It’s the natural place to start, and there’s nothing shameful about it. For two or three systems with stable interfaces, a direct link is the simplest thing that works, with the fewest moving parts, and it’s the easiest to debug.
The trouble is arithmetic. With n systems, the number of possible connections is n(n-1)/2, so ten systems can need up to forty-five separate integrations, each with its own mapping, its own error handling and its own owner. Real estates rarely reach that theoretical maximum, but they don’t have to. What really breaks point-to-point is less the number of links and more the fact that each system’s knowledge of its neighbors is buried in code. Replacing the CRM means finding and rewriting every link that touches it, and nobody is quite sure how many there are.
Hub-and-spoke
A hub-and-spoke architecture sends every exchange through a central broker. Each system connects once, to the hub, and the hub transforms messages and routes them to wherever they need to go. The number of connections grows linearly instead of quadratically, and transformation logic, monitoring and error handling all sit in one place, where people can see them and govern them.
The price is that the hub becomes a bottleneck and a single point of failure – operationally, and organizationally too. When every change has to go through the one team that owns the hub, that team’s backlog becomes the whole company’s integration backlog. Hubs also tend to collect business logic, because it’s convenient to put a rule where all the data already passes, and a hub that knows too much about the business becomes very hard to change.
Enterprise service bus
The enterprise service bus was the industry’s attempt to keep what was good about the hub while spreading out its load. Systems attach to a common bus through adapters, and messages travel across it with routing, transformation, protocol mediation and reliable delivery provided as shared services. In its idealized form, the bus is infrastructure, and nobody thinks of it as a central application.
In practice, many ESB programs reproduced the hub’s problems on a larger scale. The bus became the place where orchestration, transformation and business rules were all implemented, by a central team, in a proprietary toolset, and what came out was a tightly coupled system that just happened to be deployed as a platform. That doesn’t discredit the pattern itself. Reliable mediation between protocols, and canonical message formats, are still genuinely useful, especially in estates with mainframes, message queues and old file-based interfaces. What failed was the habit of treating the bus as the home of the business logic.
Event-driven and publish-subscribe
In an event-driven architecture, systems publish facts about what has happened – an order placed, say, or a payment settled – to a broker or stream, and any system that cares subscribes to them. The publisher doesn’t know who is listening, and you can add new consumers without touching it. Of all the patterns, this is the most loosely coupled, and it’s the natural fit for anything that has to react in real time or fan out to many destinations.
Its weaknesses mirror its strengths. Since nobody calls anybody, the end-to-end flow is harder to see, and it’s harder to answer the question an auditor will sooner or later ask: what happened to this transaction? Delivery is usually at-least-once, so consumers have to be idempotent. Ordering holds only within a partition, which makes the partitioning key an architectural decision, and much more than a configuration detail. And event-driven systems need a discipline about schemas that point-to-point integrations can get away without, because a change to an event’s shape reaches every subscriber at the same moment.
API-led layering
API-led integration arranges the estate in layers of reusable interfaces. The vocabulary MuleSoft popularized describes three of them: system APIs that expose each system of record in a stable form, process APIs that combine those into business operations, and experience APIs shaped for a particular channel or consumer. Whatever you call the layers, the principle is that each system gets wrapped once, behind a contract that hides its quirks, and everything above it builds on those contracts and never on the system directly.
The pattern works well where many consumers need governed, synchronous access to the same systems of record, and it produces genuine reuse when the layers are designed around business capabilities. It fails when the layers are applied mechanically, so that every request goes through three hops that add latency and nothing else, or when the process layer turns into a distributed ESB and collects logic in exactly the same way. It also does nothing, on its own, about the problems events solve. An API layer is still request and response, and it won’t tell anyone that something has changed.
Comparison at a glance
| Pattern | Coupling | Best fit | Characteristic failure | Typical next step |
|---|---|---|---|---|
| Point-to-point | Each system knows its partners | Two or three systems, stable interfaces, a low rate of change | Hidden dependencies; replacing one system means rewriting many links | Wrap systems of record behind APIs, or introduce events |
| Hub-and-spoke | Systems know the hub; the hub knows everything | Moderate estates that need central visibility and transformation | The hub team becomes the bottleneck; business logic piles up in the hub | Push logic back to the systems that own it; split the hub by domain |
| Enterprise service bus | Systems know the bus and a canonical format | Mixed estates with legacy protocols and queues | A central team owns every change; the bus becomes the business logic layer | Keep the mediation, move orchestration into services or APIs |
| Event-driven / pub-sub | Publishers know only the event contract | Real-time reaction, fan-out to many consumers, high volume | Flows nobody can see, duplicate handling, schemas drifting across consumers | Add tracing, a schema registry and reconciliation |
| API-led layering | Consumers know a governed contract | Many consumers that need synchronous access to the same records | Needless layers and latency; the process layer turns into a new ESB | Collapse thin layers; publish events alongside the APIs |
None of these rows wins outright. Most healthy estates combine an API layer for queries and commands with events for notification and fan-out, and they keep a few deliberate point-to-point links in the places where nothing else would justify its cost.
Choosing a pattern for the estate you actually have
Asking which pattern is best in general rarely gets you anywhere. The useful question is which kind of change the estate needs to make cheap. If the business expects to replace systems, the priority is to isolate each one behind a contract, so that a replacement touches one place. If it expects to add consumers – analytics, fraud detection, a partner portal or an AI worker – the priority is a stream of events they can attach to without negotiating with the source. If it expects neither, and the estate is small, a well-documented set of direct links may well be the honest answer, and building a platform to replace them would be a cost with no return.
Volume and latency narrow the choice further. Synchronous APIs suit interactions where a caller needs an answer now and the volumes are bounded. Events suit high volumes, many destinations and work that can go ahead asynchronously. Batch is still the right tool for work that is genuinely periodic, though it’s worth checking whether a given batch exists because the business needs it, or only because nobody has built the alternative yet.
The organization matters as much as the technology. A hub or a bus implies a central team with the capacity and the authority to own it. An event-driven or API-led design implies that domain teams will own their contracts and keep them stable. Picking a pattern the organization can’t staff is one of the most common ways integration programs fail, and it’s rarely talked about at the start.
How teams migrate between patterns
Very few estates get redesigned from scratch, and the ones that try usually regret it. Migration works when it’s incremental, and the most reliable approach I know is a version of the strangler pattern, applied to integration. You put a contract in front of one system of record, move consumers onto that contract one at a time, and retire the direct links behind it as each consumer moves. For a while, the old and new paths run side by side, with reconciliation proving that they agree, and nothing gets switched off until the evidence says it can be.
Moving from batch or point-to-point to events follows much the same path. The source starts publishing events while the existing feeds carry on, consumers attach to the stream one at a time, and each old feed is retired once its consumer has shown parity. Two disciplines keep this safe. Every consumer has to be idempotent, because replays and duplicates are certain during a migration, and every migrated flow needs a reconciliation report comparing the old path with the new one, right up until the old one is gone.
The order in which you migrate systems deserves some thought. The best first candidate is usually a system of record with many consumers and a painful history of changes, because wrapping it pays for itself straight away. The worst first candidate is the most critical system in the estate, because at that point the team hasn’t yet learned how its own migration process behaves under pressure.
From our case studies
Two pieces of eProxim’s published work show these migrations at scale. For a global post-trade financial-services firm, we replaced brittle point-to-point integrations across many systems of record with a secure enterprise API layer, plus a MuleSoft integration layer for aggregation, orchestration, scheduling, error handling and monitoring. The reporting platform built on top of it now generates more than 25 million reports a month, on demand and on schedule, and it’s still in production years after launch.
For a global financial-technology provider that connects one of the world’s largest banks to more than 16,000 correspondent institutions, we built an event-driven, in-memory settlement hub. It replaced a nightly batch that took several hours, and it sustained 240,000 transactions per second on eight commodity servers. In a third case, for a software vendor serving a national mobile operator, a single idempotent event pipeline handling 1.4 million usage events per second replaced both a nightly batch and the point-to-point links that billing, balances, alerts and fraud detection had each been maintaining. Each time, we chose the pattern for the kind of change the business needed to make cheap, and for no other reason.
Related reading
- SAP integration options: IDoc, BAPI, OData and Integration Suite
- Idempotent webhooks: duplicates, retries and out-of-order events
- Integration reconciliation reports: proving two systems agree
How we approach it at eProxim
eProxim was founded in 1997, and our published work spans payments, travel, telecom and financial services – from replacing point-to-point links with an API layer to building event-driven hubs. We don’t sell a platform, so our recommendation isn’t tied to a license. We start from the estate you actually have and the change you need to make cheap, and we plan migrations so that the old and new paths run side by side, with reconciliation, until the evidence says the old one can go.
Our approach to APIs, middleware, event-driven systems and data synchronization is described on our enterprise integration page. If you’re weighing a change to your integration architecture, or living with one that has grown well past what anyone planned, talk to us about it.