Integration patterns every team should know

Integration problems look different on the surface: an e-shop that must talk to an ERP, a warehouse system that needs stock updates, a partner that sends invoices. Underneath, they are made of a small number of recurring patterns. Teams that know these patterns make better decisions faster, and can explain those decisions to each other and to vendors.

This guide covers the patterns we use most often, what each one is good for, the mistakes we see, and how to check whether a tool supports them well. It is not a catalogue of every pattern ever named. It is the short list that covers most business integrations.

Topology: point-to-point vs hub

Point-to-point means each system connects directly to each other system it needs. It is the fastest way to build the first connection and the most expensive way to run the tenth. With n systems, the number of possible connections grows roughly with n², and every one has its own logic, credentials and failure modes.

A hub (or integration layer) puts one component in the middle. Each system connects to the hub, and the hub routes and transforms. Adding a system means one new connection, not five.

Point-to-point is still fine for two systems that will stay two systems. Once a third or fourth appears, a hub almost always pays for itself. Note that “hub” describes the logical shape, not a single server: modern integration platforms and event brokers are distributed, but play the hub role.

Timing: synchronous vs asynchronous

This is the decision with the biggest effect on reliability.

Synchronous: the caller sends a request and waits for the answer. Simple to understand, and needed when the caller can’t continue without the result (for example “is this item in stock?” during checkout). The downside is coupling: if the receiving system is slow or down, the caller is slow or down too.
Asynchronous: the caller hands the message over and continues. The work happens later, usually through a queue. Slower systems, maintenance windows and peaks are absorbed by the queue. The downside is that the caller doesn’t get an immediate result, so you need a way to report status or failures later.

A good rule: use synchronous calls for questions that need an answer now, and asynchronous messaging for commands and events that can be processed a few seconds or minutes later. We compare the two in practice in Sync vs async integration in Boomi.

Interaction styles

Request-reply

One system asks, the other answers. Usually synchronous (a REST call), but it can also be done asynchronously, with the reply sent to a reply queue and matched with a correlation ID. Request-reply is the right model for lookups, validations and anything the user is waiting for.

Fire-and-forget

The sender sends a message and doesn’t expect a business reply, only confirmation that the message was accepted. Good for commands such as “create this invoice” when a queue guarantees delivery.

Publish/subscribe

A system announces that something happened (“order 58213 was paid”) to a topic, and any number of subscribers react: the ERP creates the invoice, the warehouse prepares picking, the CRM updates the customer’s history. The publisher doesn’t know or care who listens. New consumers can be added without touching the publisher. Pub/sub is the core of event-driven architecture, covered in our event-driven integration guide.

Volume: batch vs real-time

Batch moves data in groups on a schedule: nightly price lists, hourly stock snapshots, monthly exports for the accountant. It is efficient, simple to monitor and kind to systems that dislike constant traffic.

Real-time (or near real-time) moves each change as it happens, through webhooks, events or frequent polling. It is needed when delay costs money: overselling stock, a customer waiting for confirmation.

Many flows end up in between: micro-batches every few minutes, or real-time for important changes and a nightly batch to reconcile everything else. Choose by asking how stale the data can be before it causes a problem, not by defaulting to “real-time because it sounds better”.

Data: the canonical model

When many systems exchange the same business objects (customers, orders, products), each pair of systems can have its own mapping, or every system can map to and from one shared format, the canonical data model. With a canonical model, adding a new system means writing two mappings (to and from canonical), not one for every other system.

The trade-off is design effort and governance: someone has to own the canonical model and resist turning it into “the union of every field in every system”. It works best for a few core objects that many flows share. We build one in A canonical data model in Boomi.

Reliability: idempotency

Networks fail in the worst possible place: after the receiver did the work, but before the sender got the confirmation. The sender retries, and without precautions the work happens twice. An idempotent receiver recognises a repeated message (by an order number, a message ID or a business key) and doesn’t repeat its effect.

Idempotency is what makes retries, replays and “at-least-once” delivery safe. Every create operation in an integration should have an answer to “what happens if this runs twice?”. A worked example is in Syncing e-shop orders to your ERP with Boomi.

Common mistakes

Synchronous chains. The e-shop calls the integration, which calls the ERP, which calls the warehouse system, all while the customer waits. The slowest link sets the response time, and any failure breaks the whole chain.
Real-time everything. Real-time flows are harder to monitor and recover. Use them where delay really matters.
Pub/sub without ownership. Topics that anyone can publish anything to, with no agreed message format, turn into a new kind of spaghetti.
A canonical model that tries to be everything. If it has 300 fields and every team adds more, it stops being a shared language.
Assuming exactly-once delivery. Most messaging systems deliver at least once. Design consumers to be idempotent.
No correlation IDs. Without an ID that travels with a message across systems, tracing a problem means comparing timestamps by hand.

How to compare tools

When you evaluate a platform, check how it supports the patterns you need, not just the list of connectors:

Sync and async: can it expose APIs and also consume and produce queue or topic messages, natively?
Messaging guarantees: what delivery guarantees do its queues or event streams offer, and how are failed messages handled (dead-letter queues, replay)?
State: can a flow keep a watermark or check previous runs, to support incremental loads and idempotency?
Reuse: can mappings, profiles and sub-flows be shared, so a canonical model is maintained once?
Batch and real-time: does it handle both large scheduled loads and low-latency single messages well?
Observability: can you follow one business document, by its ID, across the flows it went through?

Tools in this space

These patterns can be implemented with very different kinds of tools. These are the ones we come across most often, in alphabetical order.

Apache Camel. An open-source Java framework that implements the classic enterprise integration patterns as building blocks, with a large set of components. A strong choice for development teams that want patterns in code and are comfortable running their own services.
Apache Kafka. A distributed event streaming platform, widely used for pub/sub, event sourcing and high-volume data streams, available open source and as managed services from several vendors. It is a backbone for events rather than a complete integration tool, so mapping and connectivity usually come from other components.
Azure Integration Services. A family of Azure services (Logic Apps, Service Bus, Event Grid, API Management, Functions) that together cover workflows, messaging, events and APIs. A good fit for organisations already on Azure that are comfortable combining several services.
Boomi. A low-code integration platform where processes support request-reply APIs, scheduled batch and event-driven flows, with Boomi Event Streams adding pub/sub messaging. Profiles, maps and sub-processes can be shared across processes, which suits a canonical model. It fits best when you want these patterns available in one visual platform without assembling separate services.
MuleSoft Anypoint. An integration and API platform built around an API-led approach, with messaging and a rich developer toolset. Popular in large enterprises with dedicated integration teams.

Most real architectures combine more than one: an integration platform for connectivity and mapping, an event broker for high-volume streams, and a gateway for APIs. The patterns are what keep that combination coherent.

Where to go next

Two practical articles apply the patterns of this guide in Boomi:

Sync vs async integration in Boomi: when to wait for the answer, and how to accept a request immediately and process it in the background.
A canonical data model in Boomi: shared profiles and maps from source to canonical to target.