Integration pattern library
Compare common approaches by interaction style, coupling, latency, ownership, recovery and operational cost.
How to use the pattern library
A pattern is a reusable way to organise an interaction, not a product label. Describe the business flow and failure requirements first. Then select the simplest pattern that preserves meaning, limits coupling and can be operated by the responsible team.
| Pattern or approach | Primary purpose | Key design concern |
|---|---|---|
| Enterprise Integration Patterns | A practical map of common patterns for routing, transformation, messaging, orchestration and data movement. | store-and-forward |
| Point-to-Point Integration | When direct connections are reasonable, when they become brittle, and how to prevent uncontrolled interface sprawl. | ownership and lifecycle |
| Hub-and-Spoke Integration and the ESB | How mediated integration can centralise routing and transformation—and where excessive centralisation creates a bottleneck. | enterprise service bus |
| API-Led Integration | How reusable APIs can expose systems, compose processes and support consumer-facing experiences. | experience APIs |
| Event-Driven Architecture | How events represent meaningful state changes and allow producers and consumers to evolve independently. | consumer autonomy |
| Enterprise Messaging | Core messaging concepts for dependable asynchronous communication between systems. | delivery acknowledgements |
| Queues, Topics and Publish-Subscribe | How competing consumers differ from fan-out subscriptions, and how to choose the right channel. | consumer groups |
| Batch and File Integration | Why scheduled files remain useful and how to make them controlled, observable and recoverable. | control totals |
| Change Data Capture | How database changes can feed downstream systems without repeated full extracts. | schema changes |
| Data Virtualization | When a logical access layer can combine data without physically moving every dataset. | pushdown and caching |
| Canonical Data Models | Benefits and tradeoffs of shared enterprise representations for commonly exchanged information. | domain boundaries |
| API Integration Architecture | Designing APIs as managed interfaces with clear boundaries, contracts, consumers and operational responsibilities. | authentication and authorisation |
| ETL Versus ELT | Choosing where transformation occurs based on source constraints, target capability, governance and workload. | pushdown processing |
| Microservices Integration | Keeping service autonomy without creating a fragile web of synchronous calls and shared data. | sagas and compensation |
Do not force one style everywhere. A single business process may use a synchronous API for validation, an event for notification, a queue for durable work and a batch reconciliation for financial control.