Integration Middleware Services (Internal)
Problem
Teams running internal backend workloads need to call each other's services and share events, but their systems use different protocols and formats (REST, SOAP, gRPC, AMQP). Every system belongs to the organisation and traffic stays on its private network, so the controls are workload identity (mTLS or OAuth 2.0 client credentials) and segmentation that limits which workloads reach the integration layer. Wired pair by pair, the links multiply, each carries its own translation and orchestration code, and near-real-time delivery becomes fragile.
Solution
Run a central Integration Platform in the Private Subnet (Workloads), so internal Backend Workloads communicate through it instead of directly. It sits between them and handles protocol mediation, data format transformation, routing and reliable delivery, for both synchronous (e.g., API calls) and asynchronous (e.g., event streaming) integration.
Cloud Paradigm
- Service-Oriented Architecture (SOA) / Microservices Architecture: Enabling interoperability between distinct internal services.
- API-Led Connectivity: For exposing internal services as APIs to other internal consumers.
- Event-Driven Architecture (EDA): For asynchronous, loosely coupled communication via message brokers or event streams.
- Loose Coupling: Decoupling producers and consumers from direct dependencies.
- Infrastructure as Code (IaC): Managing the Integration Platform configuration and deployments.
Solution Flow
Synchronous Integration Flow (Request-Reply):
- Consumer Backend Workload: An internal microservice sends a synchronous request (e.g., RESTful API call) for data or a service from another Backend Workload.
- Integration Platform (API Proxy / Service Bus): The request goes to the Integration Platform, which handles:
- Authentication & Authorisation: Checks the consumer's identity and permissions (e.g., mTLS, OAuth 2.0).
- Protocol & Data Transformation: Translates the request protocol (e.g., REST to SOAP) or data format (e.g., JSON to XML) where needed.
- Routing: Sends the request to the right Provider Backend Workload.
- Traffic Management: Applies policies such as rate limiting and throttling.
- Provider Backend Workload: The target internal microservice processes the request and returns a response.
- Integration Platform: Transforms the response if needed and returns it to the Consumer Backend Workload.
- Consumer Backend Workload: Receives the processed response.
Asynchronous Integration Flow (Event-Driven):
- Publisher Backend Workload: An internal microservice generates an event (e.g., "Order Placed," "Inventory Updated") and publishes it to the Integration Platform (e.g., a Message Broker or Event Stream).
- Integration Platform (Message Broker / Event Stream): The platform receives and stores the event and makes it available to subscribers. It provides:
- Durability: Events persist until consumed.
- Fan-out: Several subscribers can receive the same event.
- Filtering: Events can be filtered by content or metadata.
- Quality of Service: At-least-once or exactly-once delivery guarantees.
- Subscriber Backend Workload(s): One or more internal microservices subscribe to specific event types or topics, then process each event asynchronously, reacting to the business change.
- Acknowledgement: Subscribers acknowledge successful processing of an event to the Integration Platform.
When to Use
- Several internal Backend Workloads speak different protocols or data formats (REST, SOAP, gRPC, AMQP), and you want one neutral bridge instead of pairwise adapters.
- You need synchronous request-reply and asynchronous event-driven communication managed under one governed platform.
- Decoupling producers from consumers matters: publishers should not know or care which services subscribe to their events.
- Critical internal flows need delivery guarantees (at-least-once, exactly-once), durability and fan-out.
- Many internal integrations need central policy enforcement: authentication, rate limiting, routing and canonical schema validation.
When NOT to Use
- Two stable services share protocols and formats, so a direct call or shared library adds far less latency and operational overhead.
- Ultra-low-latency, high-throughput paths cannot tolerate an extra hop through a broker or proxy.
- The integration is with external partners or the public, where an edge API gateway or B2B gateway in a DMZ is the right pattern.
- Your team cannot operate, scale and govern a highly available platform; an under-resourced hub becomes a fragile single point of failure.
- Transfers are simple one-way file or batch moves, where scheduled ETL or a managed data pipeline fits better.
Trade-offs
- Loose coupling and protocol/format neutrality vs the work of running, scaling and versioning a central platform.
- Centralised security, routing and traffic policy vs added latency from the extra network hop and transformation processing.
- Reliable, durable, fan-out delivery for events vs the complexity of managing schemas, offsets and exactly-once semantics.
- End-to-end observability and governance vs the discipline needed to keep contracts, canonical models and configuration-as-code in step.
- A single integration control point vs the risk that it becomes a bottleneck or single point of failure without a high-availability design.
Illustrative Scenario
A hypothetical scenario showing how the pattern applies. Not a client case study.
Suppose a property-management firm, invented for this example, has a tenancy microservice that must tell the bond-lodgement, access-card issuance and tenant-notification workloads the moment an application is approved. Rather than wiring three point-to-point calls, the tenancy service publishes a Tenancy Approved event to the central Integration Platform's message broker in the private workload subnet. The platform persists the event and fans it out to each subscriber. A filter means access-card issuance only handles buildings that have card access.
Separately, the tenancy service needs a synchronous reference check against a legacy SOAP-based screening system. The same platform proxies that REST call: it translates JSON to XML, enforces mTLS and OAuth 2.0, and applies rate limiting before returning the reply. Canonical schemas and AsyncAPI contracts keep both styles governed, so neither workload needs to know the other's protocol. Adding a fourth subscriber later means subscribing to the topic, not changing the tenancy service.
Additional Details
- Integration Platform Components: The platform may combine API Management gateways (for internal API exposure), Enterprise Service Bus (ESB) capabilities for complex orchestration, message brokers (e.g., Kafka, RabbitMQ) for event streaming, and lightweight service proxies.
- Protocol & Format Neutrality: Support many protocols (e.g., HTTPS, AMQP, gRPC, proprietary protocols) and data formats (e.g., JSON, XML, Protobuf, Avro), so Backend Workloads need not be directly compatible.
- Data Models & Schemas: Require canonical data models and well-defined schemas (e.g., JSON Schema, Avro Schema), so data stays consistent and can be validated.
- API/Event Design & Documentation: Document every synchronous API and asynchronous event contract with an industry-standard specification (e.g., OpenAPI Specification, AsyncAPI Specification).
- Observability: Collect logs, metrics (e.g., request volume, latency, error rates, message throughput) and distributed traces (e.g., OpenTelemetry) across the whole Integration Platform.
- Resilience & Scalability: Design the platform for high availability, fault tolerance and horizontal scaling, so it does not become a single point of failure or a bottleneck for critical internal traffic.
- Governance: Set clear policies for defining, building and managing integration interfaces and data contracts.
- Configuration as Code: Keep all platform configuration (e.g., routes, transformations, security policies, topic definitions) in version control and deploy it through automated CI/CD pipelines.
Security Controls
- Transport Security: Enforce TLS 1.2 or higher on every interface of the Integration Platform, including its connections to consumer and provider workloads.
- Authentication & Authorisation:
- For system-to-system integrations, authenticate internal consumer Backend Workloads with OAuth 2.0 (Client Credentials Grant) or Mutual TLS (mTLS).
- Use granular role-based access control (RBAC) to define which Backend Workloads can reach specific integration endpoints or topics.
- Network Segmentation: Deploy the Integration Platform in a dedicated, isolated private subnet or network segment, with internal network access controls (e.g., Security Groups, Network ACLs) that admit traffic only from authorised internal Backend Workloads.
- Traffic Management: Apply rate limiting, throttling and circuit breakers in the Integration Platform to protect provider Backend Workloads from surges of internal traffic.
- Data in Transit Protection: Encrypt sensitive data end to end as it passes through the Integration Platform, and consider tokenisation or masking for highly sensitive fields.
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-internal), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).