Integration Platforms & Middleware
The pattern (API-led, event-driven, etc.) is the design; the platform is what actually runs it day to day.
At a glance
Section titled “At a glance”- What it is: The infrastructure/tooling categories used to build and run integrations: an ESB (Enterprise Service Bus, routing plus transformation in one shared bus), an iPaaS (Integration Platform as a Service, a hosted platform for building connectors and flows without managing the underlying infrastructure), an API gateway (the entry point for exposed APIs — auth, rate limiting, routing), a service mesh (handles service-to-service traffic concerns like retries and mTLS inside a single application platform), and EDI (Electronic Data Interchange, structured document exchange like purchase orders and invoices with external trading partners).
- Why it matters: Each platform solves a different layer of the integration problem — using an ESB for what an API gateway does (or vice versa) usually means paying for capability you don’t need, or missing capability you do.
- For developers: if you’re building a new integration and reaching for “let’s just write a script that runs on a cron job,” check first whether the org already has an iPaaS or gateway that does retries, monitoring, and auth for you out of the box.
- When to use it: Whenever choosing where an integration pattern (from Integration Patterns & Styles) will actually run.
- When not to use it: Don’t introduce a new platform category just because it’s available — match the platform to the actual integration need first.
- Prerequisites: Integration Patterns & Styles.
Mental model
Section titled “Mental model”graph TD
GW[API Gateway] -->|exposes| EXP[Experience APIs]
IPAAS[iPaaS] -->|hosts connectors/flows for| SAAS[SaaS & partner systems]
ESB[Legacy ESB] -->|routes + transforms for| LEGACY[Legacy backend systems]
MESH[Service Mesh] -->|secures traffic between| INTERNAL[Internal microservices]
EDI[EDI Gateway] -->|exchanges documents with| PARTNER[External trading partners]
These platforms are not mutually exclusive — a real landscape typically runs a gateway in front of experience APIs, an iPaaS for SaaS/partner connectors, and (in older estates) a legacy ESB still in the process of being retired.
Step-by-step walkthrough
Section titled “Step-by-step walkthrough”- Identify what the integration actually needs: exposing an API to consumers (gateway), connecting to SaaS/partner systems with prebuilt connectors (iPaaS), securing internal service-to-service traffic (service mesh), or exchanging structured documents with an external trading partner (EDI).
- Check whether an existing platform in the landscape already covers that need before introducing a new one.
- For legacy ESB workloads, evaluate case by case whether each integration should be modernized onto an iPaaS/gateway or left as-is, rather than attempting a single big-bang migration.
- Match ownership to the platform: gateway and iPaaS configuration is usually owned by a platform/integration team, not by each individual project.
- Confirm the chosen platform supports the resilience and security needs from Resilience & Error Handling in Integration and Integration Security & Governance before committing.
Worked example
Section titled “Worked example”A legacy ESB currently handles B2B EDI purchase orders from a large retail partner, translating the partner’s EDI document format into the internal order format. The ESB is expensive to change and the team wants to onboard several new, smaller partners without expanding it.
- Input: one legacy ESB doing routing, EDI translation, and business rules for a single big partner, with no easy way to onboard new partners.
- Process: introduce an iPaaS with prebuilt EDI connectors for new partner onboarding, plus an API gateway for any partners that support modern APIs instead of EDI. The legacy ESB continues serving the original large partner (not worth migrating immediately) while all new integrations go through the iPaaS/gateway combination.
- Output: new partner onboarding time drops significantly since the iPaaS connectors don’t need custom-built translation logic, and the legacy ESB’s footprint stops growing — a natural, gradual (strangler-style) path to eventually retiring it. On Azure, new partners onboard through Azure Logic Apps (iPaaS, with prebuilt EDI/X12 connectors) behind Azure API Management, while the legacy ESB is left untouched until it’s eventually strangled out.
Common use cases
Section titled “Common use cases”| Use case | Platform | Notes |
|---|---|---|
| Exposing internal APIs to external or partner consumers | API gateway | Handles auth, rate limiting, routing — see Integration Security & Governance |
| Connecting to many SaaS products or partners with prebuilt connectors | iPaaS | Reduces custom integration code for common systems (CRM, ERP, etc.) |
| Securing traffic between internal microservices | Service mesh | Adds mTLS, retries, and observability without changing application code |
| Exchanging purchase orders/invoices with external trading partners | EDI (often via iPaaS or dedicated EDI gateway) | Structured document standards (e.g. X12, EDIFACT) rather than free-form APIs |
| Legacy backend systems needing heavy format translation | ESB (often being phased out) | Increasingly replaced by iPaaS + gateway for new work |
Advanced details
Section titled “Advanced details”- ESB modernization is incremental: retire an ESB integration-by-integration (strangler pattern), not as a single cutover — see the worked example.
- iPaaS vs. custom code: an iPaaS trades some flexibility for faster connector development and built-in monitoring/retry — worth it for common SaaS/partner integrations, less so for highly bespoke logic.
- Service mesh scope: a service mesh addresses internal service-to-service traffic; it’s not a substitute for an API gateway at the edge or an iPaaS for external partner connectivity.
Quick reference
Section titled “Quick reference”| Term | Meaning |
|---|---|
| ESB | Enterprise Service Bus — shared bus for routing and message transformation |
| iPaaS | Integration Platform as a Service — hosted platform for connectors and integration flows |
| API gateway | Entry point for exposed APIs handling auth, rate limiting, and routing |
| Service mesh | Infrastructure layer securing and observing service-to-service traffic |
| EDI | Electronic Data Interchange — structured document exchange with external trading partners |
Troubleshooting
Section titled “Troubleshooting”| Symptom | Likely cause | Fix |
|---|---|---|
| Onboarding a new partner takes weeks of custom code | No iPaaS, integrations hand-built each time | Introduce an iPaaS with prebuilt connectors for common partner/SaaS integration patterns |
| Legacy ESB is a bottleneck for every new integration | All new work still routed through the ESB by default | Route new integrations through an iPaaS/gateway instead, leaving the ESB to shrink over time |
| Internal service-to-service calls have no consistent retry/mTLS behavior | No service mesh, each service handling this ad hoc | Introduce a service mesh to standardize it infrastructure-wide |
Check your understanding
Section titled “Check your understanding”- Why did the worked example leave the original large partner on the legacy ESB instead of migrating everything at once?
- What’s the difference in scope between a service mesh and an API gateway?
Related pages
Section titled “Related pages”Part of Introduction to Integration Architecture. Builds on Integration Patterns & Styles; see also Integration Security & Governance for gateway-level controls, and the Glossary for term definitions.