Integration Middleware Services (External)
Problem
A team whose backend workload exchanges data with a partner finds that a direct API is not enough: the partner uses another protocol or format, or needs asynchronous messaging, in both directions. The partner owns the far end and connects over the Public Internet, so its traffic must stop at a WAF and API Gateway (or message proxy) in the perimeter, authenticate with OAuth 2.0 or mutual TLS, and never touch the internal Message Broker. Built into each workload, that mediation gets rebuilt for every partner feed, with no shared governance.
Solution
Run an Integration Platform in the Private Subnet (Workloads) for transformation, protocol adaptation and orchestration. Inbound synchronous requests terminate at an API Gateway in the Public Subnet (Perimeter), which routes them through the Integration Platform to the backend workload. Outbound synchronous calls go through a Managed NAT / Egress Gateway. For asynchronous exchange, a Message Broker sits in the Private Subnet (Workloads), and external publishers and subscribers reach it only through a proxy or adapter in the Public Subnet (Perimeter), so the broker is never exposed to the Public Internet.
Cloud Paradigm
- Event-Driven Architecture: Message brokers for decoupled, asynchronous communication between systems.
- API-Led Connectivity: Controlled synchronous interfaces exposed through API Gateways.
- Integration Platform as a Service (IPaaS) / Middleware-as-a-Service: Managed services or dedicated platforms for complex integration logic, data transformation and protocol mediation.
- Edge Security & Control: Controlled ingress and egress points in the Public Subnet (Perimeter) for every external interaction.
- Zero Trust Architecture: No implicit trust; every request and connection across network boundaries is verified.
Solution Flow
Inbound Integration Flow (External to Internal):
- External Initiator: An external system or application starts an exchange: a synchronous API call or an asynchronous message publication.
- Public Subnet (Perimeter) Entry:
- Synchronous: Traffic passes a Web Application Firewall (WAF) and an API Gateway, which check for malicious signatures, enforce rate limits, authenticate the caller and terminate TLS.
- Asynchronous: Traffic passes a Web Application Firewall (WAF) and a secure, managed proxy/adapter in the Public Subnet (Perimeter), which validates the sender and forwards the message to the internal Message Broker. The broker has no direct Public Internet access.
- Integration Platform / Middleware Service: The request (synchronous) or message (asynchronous) is routed to the Integration Platform in the Private Subnet (Workloads) for protocol translation (e.g., SOAP to REST), data mapping, enrichment and orchestration of several internal services.
- Backend Workload: The transformed request goes to the target internal microservice or application for business processing. Synchronous responses take the reverse path.
- Message Broker (for Async): For asynchronous inbound, the Integration Platform may publish messages to an internal Message Broker for several backend workloads to consume.
Outbound Integration Flow (Internal to External):
- Backend Workload / Integration Platform: An internal service or the Integration Platform needs to send data to, or invoke, an external service.
- Message Broker (for Async): For asynchronous outbound, the internal service publishes a message to the internal Message Broker, and the Integration Platform consumes it.
- Integration Platform / Managed NAT / Egress Gateway:
- Synchronous: The Integration Platform (or the backend workload, if no transformation is needed) sends an HTTPS request through a Managed NAT / Egress Gateway for central egress filtering, FQDN allow-listing and network address translation.
- Asynchronous: The Integration Platform consumes the message from the internal Message Broker, transforms it and sends it out through the Managed NAT / Egress Gateway.
- External Target: The partner system or external service receives the request from a static, allow-listed cloud egress IP.
When to Use
- The integration needs protocol translation (e.g., SOAP-to-REST, AMQP-to-HTTP) or non-trivial data mapping and enrichment that a direct API call cannot provide.
- Inbound consumption by external parties and outbound publication to external destinations must coexist under one governance model.
- Asynchronous exchange needs a Message Broker with DLQ handling and retries, but the broker must never be exposed to the Public Internet.
- Several backend workloads consume or produce shared external feeds, so central orchestration and fan-out pay off.
- Outbound calls to partners need static, allow-listed egress IPs and FQDN filtering, for compliance or for the partners' own allow-lists.
When NOT to Use
- A backend exposes a clean REST/JSON contract that external systems can call directly: a plain API Gateway pattern is enough, with no middleware tier.
- Simple, low-volume file drops fit a managed SFTP or object-storage exchange better than a full Integration Platform.
- Purely internal service-to-service messaging needs no perimeter proxy or egress gateway; use an internal event bus.
- Ultra-low-latency, high-frequency (trading-style) paths cannot absorb the overhead of the transformation hop.
- One-off or throwaway integrations, where the cost of running and observing a middleware platform outweighs the benefit.
Trade-offs
- Decoupling and protocol flexibility vs the work of running, patching and scaling a dedicated Integration Platform and Message Broker.
- Centralised transformation and governance vs an extra network hop that adds end-to-end latency to synchronous flows.
- No direct broker exposure, thanks to the perimeter proxy vs extra perimeter components (WAF, proxy/adapter) that widen the attack surface to secure.
- Static allow-listed egress and FQDN filtering vs managing NAT/Egress Gateway IP allow-lists as partners change.
- Rich error handling, DLQs and retries vs the complexity of end-to-end observability and distributed tracing across many moving parts.
Illustrative Scenario
A hypothetical scenario showing how the pattern applies. Not a client case study.
A hypothetical industrial equipment manufacturer coordinates just-in-time deliveries with hundreds of parts suppliers, many of which still send EDI documents and legacy flat files. Inbound purchase-order acknowledgements terminate at a WAF and API Gateway in the perimeter. From there they go to an Integration Platform in the private subnet, which translates EDI and SOAP into REST, maps part numbers and enriches the payloads before handing them to the ERP and MES backend workloads.
Shop-floor telemetry arrives over MQTT through a managed adapter that validates each sender and forwards the messages to the internal Message Broker, which is never exposed publicly. Replenishment signals are published asynchronously; the platform consumes and transforms them, then pushes them to supplier endpoints through a Managed NAT Gateway, so every outbound call comes from a static, allow-listed egress IP. DLQs catch malformed dispatch advices for automated reprocessing, and distributed tracing follows each message across the whole chain.
Additional Details
- Protocol & Format Mediation: The Integration Platform mediates between protocols (e.g., REST, GraphQL, gRPC, SOAP, AMQP, MQTT) and data formats (e.g., JSON, XML, Protobuf, custom flat files).
- Data Transformation & Enrichment: Provide data transformation (e.g., ETL, ESB-like functions) to adapt schemas and enrich payloads to business requirements.
- Error Handling & Retry Mechanisms: Give the Integration Platform full error handling, dead-letter queue (DLQ) support for asynchronous patterns, and configurable retry policies for transient failures.
- Integration Management & Lifecycle: Treat integration configurations and flows as code (IaC/GitOps), with version control and automated deployment through CI/CD pipelines.
- Observability: Monitor the whole integration chain: API Gateway, Integration Platform, Message Broker and Egress Gateway. Use centralised logging, metrics (latency, error rates, throughput) and distributed tracing (e.g., OpenTelemetry) to follow cross-boundary interactions and find bottlenecks or failures quickly.
- Scalability & Resiliency: Design the Integration Platform and Message Broker for high availability and elastic scaling, so service continues under fluctuating load.
Security Controls
-
Perimeter Security:
- Inbound Synchronous: API connections terminate at an API Gateway in a Public Subnet (Perimeter), behind a Web Application Firewall (WAF) that blocks common attacks (e.g., OWASP Top 10) and malicious bot traffic.
- Inbound Asynchronous: External publishers and subscribers connect to a secure, managed proxy or adapter in the Public Subnet (Perimeter), also behind a Web Application Firewall (WAF), which relays messages to the internal Message Broker. Direct Public Internet access to the broker is prohibited.
-
Transport Security: Enforce TLS 1.2 or higher on all inbound and outbound endpoints, including between Public Subnet (Perimeter) components and Private Subnet (Workloads) services.
-
Authentication & Authorisation:
- Synchronous API Consumers:
- Authenticate system-to-system (B2B) consumers with OAuth 2.0 (Client Credentials Grant) or Mutual TLS (mTLS).
- Authenticate external users with OAuth 2.0/OpenID Connect (OIDC).
- Asynchronous Message Consumers/Producers: Authenticate external parties with client certificates (mTLS) or secure token exchange at the perimeter proxy/adapter, never directly against the internal Message Broker.
- Note: API keys are for basic identification or quota management, not primary authentication.
- Synchronous API Consumers:
-
Traffic Management:
- Synchronous: API Management policies enforce rate limits, throttling and burst quotas on inbound API requests.
- Asynchronous: Flow control on the Message Broker or its perimeter proxy/adapter stops internal services from being overwhelmed.
-
Outbound Controls: Configure the Managed NAT / Egress Gateway and egress Web Application Firewall (WAF) to allow outbound connections only to listed external IP addresses or fully qualified domain names (FQDNs). Inspect outbound traffic for Data Loss Prevention (DLP) if compliance requires it.
Related Patterns
Use and cite this
Free to use and adapt under CC BY 4.0. Credit: David Tirabassi, IT Architecture Patterns.
Attribution: Source: David Tirabassi, IT Architecture Patterns (https://www.itarchitecturepatterns.net/patterns/int-middleware-external), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).