Enterprise integration patterns fall into two groups: topologies, which describe how many systems are wired together (point-to-point, hub-and-spoke through middleware, or a bus of events), and message patterns, which describe how data moves along each wire (request-reply, publish-subscribe, scheduled batch, change data capture). Choose the topology by the number of systems and the rate of change, and choose the message pattern flow by flow by how fresh the data must be.
This guide takes a different angle from our comparison of system integration approaches, which covers the platforms (middleware, iPaaS, direct APIs, file transfer) and the operational practices around them. Here the question is architectural: which pattern fits which flow, and when does a connection become an architecture? If you are deciding for an organization with many systems, see our enterprise system integration architecture page; if the centre of your problem is an ERP, see ERP integration services; for a single connection or an API build, see systems and API integration.
What are the three integration topologies?
Point-to-point. Each pair of systems that must share data has its own connection, with its own mapping and error handling. Two or three systems need one to three connections. The count of possible connections between n systems is n x (n - 1) / 2, so six systems can need 15, ten need 45 and twenty need 190. The topology is not wrong; it just stops scaling because every change in one system touches every connection to it.
Hub-and-spoke (middleware or integration platform). Every system connects once to a central hub that routes and transforms messages. Adding a system adds one connection rather than several. The cost is a central component that needs hosting, monitoring, skills and care, and that can become a bottleneck or a single point of failure if it is not designed for resilience.
Event-driven (bus or broker). Systems publish facts (an order was placed, an invoice was approved) to a broker, and other systems subscribe to the events they care about. Publishers do not know who listens. This decouples systems in time and in knowledge: a subscriber can be down for an hour and catch up, and a new subscriber can be added without changing the publisher. The cost is design discipline: event names and payloads need governance, ordering and duplicates must be handled, and troubleshooting requires tracing across systems.
What are the main message patterns?
| Pattern | How data moves | Good for | Trade-offs |
|---|
| Request-reply (synchronous API) | One system calls another and waits for the answer | Lookups and actions needing an immediate result: price check, stock availability, payment authorization | Both systems must be up at once; slow callee slows the caller |
| Publish-subscribe | A system announces an event; any number of subscribers react | Order created, customer updated, shipment dispatched | Needs a broker; consumers must tolerate duplicates and out-of-order delivery |
| Scheduled batch | A job moves a set of records at intervals | Nightly accounting postings, daily reporting extracts | Data is as old as the last run; large batches need windows |
| File transfer | Structured files over a secure channel | Banks, government portals, older systems | Slow; format changes must be validated |
| Change data capture | Reads a database change log and publishes changes | Keeping a reporting store or a new system in step with an old one | Needs database access and care with schema changes; exposes internal data structures |
| Transactional outbox | A system writes its event into its own database in the same transaction as the business change, and a relay publishes it | Avoiding "saved the order but lost the event" | Extra table and relay process to run |
| API facade or gateway | A thin layer in front of one or more systems with one stable interface | Hiding a legacy system or giving partners a single endpoint | One more component; must be versioned |
Two supporting ideas appear in most designs. A canonical data model is an agreed shape for shared records (customer, order, invoice) that every system maps to and from, so n systems need n mappings instead of n squared. It pays off with many systems and costs governance effort; with three systems it is usually over-engineering. Orchestration versus choreography describes who coordinates a multi-step process: one conductor service that calls each step in order, or independent services reacting to each other's events. Orchestration is easier to follow and audit; choreography is more flexible but harder to trace.
How do you choose a topology?
| Question | If the answer is... | Lean towards |
|---|
| How many systems exchange data? | 2 to 4 | Point-to-point APIs |
| 5 or more, or growing | Hub or event broker |
| How often does a system change or get added? | Rarely | Point-to-point |
| Often | Hub or events |
| Must one system keep working while another is down? | No | Request-reply is acceptable |
| Yes | Queues or events |
| How fresh must data be? | Seconds | Request-reply, events or change data capture |
| Hours or a day | Scheduled batch |
| Who will run it? | A small engineering team | The simplest pattern that works |
| Operations staff with a platform team | Configured platform with engineers for hard cases |
| Do you need an audit trail of every exchange? | Yes | A hub or broker with logging by design |
Treat the table as a guide to the conversation, not a verdict. Real estates use more than one pattern at the same time.
An illustrative decision walk-through
The numbers here are invented for illustration. A distributor runs an ERP, a web store, a warehouse scanner app, a CRM and an accounting package, with a payment gateway and one courier. That is seven systems.
- Order from web store to ERP. The customer waits for confirmation, but the ERP can acknowledge asynchronously. Publish an "order placed" event; the ERP and the warehouse app subscribe. Pattern: events.
- Stock level back to the store. Within a minute is fine. Publish stock changes from the ERP; the store subscribes. Pattern: events, with a scheduled full comparison as a safety net.
- Payment authorization. Needs an immediate answer. Pattern: request-reply to the gateway, with idempotent retries.
- Invoice postings to accounting. Nightly is acceptable. Pattern: scheduled batch, with a reconciliation report.
- Customer updates between CRM and ERP. Neither should overwrite the other blindly. Pattern: events from the system that owns each field, plus matching rules.
- Courier labels and tracking. The courier offers an API. Pattern: request-reply plus webhooks.
With seven systems and five patterns, a broker plus a small set of well-built request-reply integrations is easier to run than 21 direct links. With three systems, direct APIs would be simpler.
How do these patterns apply to an ERP-centred estate?
In most mid-sized organizations the ERP is the system of record for items, customers, stock and the ledger, so most flows start or end there. A practical default is to let the ERP publish the facts it owns (item changes, stock movements, invoice posted) and let other systems subscribe, while systems that originate data (a web store creating an order, a field app capturing a delivery) send it to the ERP through a queue or a request-reply call. Reporting stores are usually fed by change data capture or a nightly batch, so analytics never put load on the ERP. This keeps ownership clear and avoids the ERP calling out to ten systems synchronously during a posting. The detail for ERP-specific work, including accounting and e-commerce examples, is on our ERP integration services page.
What makes event-driven integration harder than it looks?
- Duplicates and ordering. Brokers commonly deliver at least once, so consumers must be idempotent. Events about the same record may arrive out of order; include a version or timestamp.
- Schema change. Adding a field is easy; renaming one breaks subscribers. Version events and keep old versions during transition.
- Debugging. A single business action may touch five systems. Pass a correlation identifier through every message so you can trace it.
- Dead letters. Messages that fail repeatedly need a quarantine queue, an alert and an owner.
- Ownership. Each event type needs a publishing system and a named owner of its definition.
The practices behind these points, including retries, monitoring and security, are covered in the system integration approaches guide.
When is a pattern the wrong answer?
- Two systems, one flow. A direct API call with retries is enough.
- A one-time migration. Use a migration script, not an integration platform.
- No one to operate it. A sophisticated broker without monitoring becomes the next legacy system.
- The systems should be one system. If two applications constantly share and fix the same records, consolidating them may cost less than integrating them.
A short adoption path
- List the systems and the data each one owns.
- List the flows between them with direction, freshness and volume.
- Assign a message pattern to each flow using the tables above.
- Count the systems and the expected growth, then choose the topology.
- Build the two or three most valuable flows first, with monitoring and reconciliation, and prove them.
- Add flows in phases, keeping the system map and data contracts up to date.
Working with Timeline Digital
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. We design and build integration layers, from direct API connections to brokers and middleware, as tested code in a repository you own, with a system map, data contracts and monitoring. Our enterprise integration architecture page describes the scope. There is no fixed timeframe: the schedule is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a complete system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Long-term support under a service level agreement (SLA) follows launch. Timeline Digital does not publish prices for custom software, because every project is custom.
About the author and publisher
This guide was written by Usama Asif, CEO and CTO of Timeline Digital. It describes general integration design practice; product names are deliberately omitted so the patterns apply whichever platform you choose.