Integration is rarely a one-time project. As you add SaaS tools, modernise legacy platforms, and expand data pipelines, the connections between systems multiply. Without a deliberate pattern, you end up with point-to-point spaghetti that breaks silently and costs a fortune to maintain.
This article surveys the most common integration patterns used in enterprise environments, when each makes sense, and the trade-offs you should weigh before committing. For delivery support, see our integration and automation service.
Point-to-point integration
The simplest pattern: System A calls System B directly via REST, SOAP, or a database link. It works for early-stage connections where you have two systems and a well-defined data exchange.
Strengths:
- Fast to implement for a single connection
- No additional middleware infrastructure
- Easy to debug when there are only two parties
Weaknesses appear quickly as you scale:
- Every new system requires N new connections (the N² problem)
- Schema changes in one system ripple across many consumers
- No central visibility into traffic, errors, or latency
- Authentication and rate limiting duplicated in every integration
When to use: Prototypes, proofs of concept, or stable two-system connections with low change frequency. Plan to refactor before you exceed five or six direct integrations.
Hub-and-spoke (mediated integration)
A central hub — often an enterprise service bus (ESB), iPaaS platform, or custom middleware layer — routes messages between systems. Each system connects only to the hub, not to every other system.
This pattern excels when you have many systems exchanging data in predictable formats. The hub handles transformation, routing, retry logic, and protocol conversion in one place.
- Pros: Reduced coupling, centralised monitoring, reusable transformations
- Cons: Hub becomes a single point of failure; can become a bottleneck if not scaled; ESB projects have a reputation for over-engineering
Modern iPaaS tools (MuleSoft, Boomi, Workato) lower the barrier, but the architectural principle is the same: one mediation layer instead of many direct pipes.
API gateway pattern
An API gateway sits in front of your internal services and external consumers, providing a single entry point for authentication, rate limiting, routing, and versioning. Unlike a full ESB, gateways focus on HTTP/API traffic rather than general message transformation.
Use an API gateway when:
- You expose APIs to partners, customers, or mobile apps
- Multiple backend services need consistent security policies
- You want to decouple external API contracts from internal service implementations
- Traffic shaping, caching, or request aggregation is required at the edge
Popular options include Kong, AWS API Gateway, Azure API Management, and Apigee. Pair the gateway with an internal service mesh only if your microservices complexity genuinely warrants it — many organisations adopt a gateway without needing full mesh infrastructure.
Event-driven integration
Instead of systems calling each other synchronously, they publish events to a message broker or event stream. Interested consumers subscribe and react independently. This decouples producers from consumers in both time and knowledge — the publisher does not need to know who is listening.
Common implementations use Apache Kafka, AWS EventBridge, Azure Service Bus, or RabbitMQ. Event-driven patterns suit:
- High-volume, near-real-time data flows (order processing, inventory updates)
- Scenarios where multiple systems need the same data without the source orchestrating delivery
- Audit trails and event sourcing architectures
- Systems with different availability requirements (async tolerance)
The trade-off is complexity: you need robust schema governance, dead-letter handling, idempotency, and observability across async boundaries. Debugging a failed event chain is harder than tracing a synchronous HTTP call.
Batch and file-based integration
Not everything needs real-time APIs. Nightly batch jobs, SFTP file drops, and scheduled ETL pipelines remain valid patterns — especially for legacy systems, large data volumes, or partners who only support file exchange.
Best practices for batch integration:
- Define clear file formats with versioning and validation rules
- Use idempotent processing so re-runs do not duplicate data
- Monitor for missing files and processing failures with alerting
- Document SLAs for delivery windows and error notification
Hybrid architectures often combine real-time APIs for transactional flows with batch pipelines for analytics, reconciliation, and bulk imports.
Choosing the right pattern
No single pattern fits every integration. Use this decision guide:
- Two systems, low volume, stable schema? Point-to-point is fine — for now
- Many systems, varied protocols, central governance needed? Hub-and-spoke or iPaaS
- External API exposure with security and versioning? API gateway
- Multiple consumers, async tolerance, high throughput? Event-driven
- Legacy partner, large volumes, scheduled exchange? Batch/file-based
Integration decisions also intersect with build-vs-buy choices — see our guide on build vs buy software for how integration complexity should influence procurement. For organisations modernising legacy estates, pairing integration work with a phased modernisation approach reduces the risk of breaking existing connections mid-migration.
Conclusion
Enterprise integration succeeds when you match the pattern to the coupling, volume, latency, and governance requirements of each connection — not when you apply the same approach everywhere. Start simple, instrument early, and refactor toward event-driven or gateway patterns as your system count and traffic grow. The goal is reliable data flow that your operations team can monitor, your developers can extend, and your business can depend on.
Need to connect systems reliably?
We design and deliver enterprise integrations — from API gateways to event-driven pipelines — that scale with your architecture.