Integration Native Connectors (Internal)
Problem
Two backend workloads your organisation runs in the same private subnet need to call each other, and both already have SDKs or client libraries for it. The calls never leave the private network, where TLS, service credentials (OAuth 2.0 or JWTs) and security groups protect them, so forcing them through a dedicated integration platform only adds latency, cost and operational overhead.
Solution
Let the workloads call each other directly over the private network with their native components or vendor SDKs. Secure the link with TLS (mTLS where configured), OAuth 2.0 client credentials or JWTs, and RBAC, and confine it with security groups or NACLs.
Cloud Paradigm
- Direct Service-to-Service Communication
- Component-based Integration
- Microservices Interoperability
- Private Network Communication (Zero Trust principles)
- High-Performance Internal Integration
Solution Flow
Internal Service Interaction Flow:
- Consuming Backend Workload: An internal microservice or application component in a private subnet requests data or a service from another internal workload.
- Native Integration Component: The consumer connects through its pre-configured native component (e.g., a direct API call via SDK, a message queue client, a shared library).
- Transport Security & Authentication: TLS 1.2+ (and mTLS if configured) secures the channel. The provider authenticates the consumer (e.g., via OAuth 2.0 Client Credentials or JWTs).
- Providing Backend Workload: The target microservice receives the request, checks authorisation (RBAC), runs the business logic and returns the response securely over the private network.
When to Use
- Two or more internal workloads share a private subnet or trust boundary and need low-latency, high-throughput exchange.
- One team or organisation owns both services, so data contracts can be tightly coupled without governance friction.
- Vendor SDKs, client libraries or native message queue clients already provide the connectivity and security primitives.
- You want to avoid the cost and latency of routing intra-service traffic through an integration platform or gateway.
- Communication patterns are stable and well understood, suiting direct REST/gRPC or asynchronous messaging.
When NOT to Use
- Workloads span trust boundaries or VPCs, or must cross the public internet. Use a gateway or B2B integration pattern.
- External partners or third parties need mediation, throttling and monetisation. An API management platform fits better.
- Many heterogeneous services need central routing, transformation and orchestration. Prefer an ESB or iPaaS.
- Loose coupling and independent evolution are paramount, making tight native coupling a liability.
- Mismatched systems need protocol translation or complex message transformation.
Trade-offs
- Minimal latency and overhead vs tight coupling that makes independent deployment and versioning harder.
- Lower cost without an integration platform vs resilience logic (retries, circuit breakers) duplicated in each workload.
- Simple direct SDK/library calls vs a larger blast radius when a shared library or contract changes.
- Full control of transport security (mTLS, JWT) vs keeping auth and observability consistent at every integration point.
- High throughput within the private subnet vs limited portability if workloads later move across network boundaries.
Illustrative Scenario
A hypothetical scenario showing how the pattern applies. Not a client case study.
Take a hypothetical university whose student-enrolment microservice and course-catalogue service run side by side in the same private subnet, behind the registration portal. When a student registers, the enrolment workload calls the catalogue service directly through its vendor-supplied gRPC SDK. The call runs over mTLS and carries an OAuth 2.0 client-credentials token, with no hop through a shared integration platform. Both services belong to the same university IT team, so the data contract between them can change in step. The catalogue service enforces RBAC, checks seat availability and prerequisites, and returns a Protobuf response. OpenTelemetry traces span both workloads, so the operations team can watch latency and error rates during the busy add-drop period. The enrolment service wraps each call in retries with exponential backoff and a circuit breaker. That way a brief catalogue outage does not take registration down when thousands of students log in at 8 a.m. on opening day.
Additional Details
- Protocol & Format: Use synchronous protocols (e.g., REST, gRPC) or asynchronous messaging (e.g., message queues) over secure internal channels, with standard formats such as JSON or Protobuf.
- Observability: Collect distributed traces (e.g., OpenTelemetry), central logs and metrics (latency, error rates) for both workloads.
- Version Management: For API-driven integrations, adopt a clear versioning strategy (e.g., semantic versioning) so consuming services stay backward compatible.
- Resilience & Failure Handling: Use error handling, retries with exponential backoff, circuit breakers and bulkheads to contain transient failures in dependent services.
- Documentation: Document every integration point: endpoints, data contracts, authentication, error codes and operational runbooks.
- Cost Optimisation: Avoiding a separate integration platform usually cuts operational overhead and can lower the cost of intra-service communication.
Security Controls
- Transport Security: Enforce Transport Layer Security (TLS 1.2 or higher) for all inter-service traffic on the private network, adding mutual TLS (mTLS) for peer authentication where stronger assurance is needed.
- Authentication & Authorisation: For service-to-service calls, use OAuth 2.0 (Client Credentials Grant), JSON Web Tokens (JWTs) or API Keys backed by internal identity providers, with fine-grained Role-Based Access Control (RBAC) for least privilege.
- Network Segmentation: Keep workloads in isolated private subnets and use Security Groups or Network Access Control Lists (NACLs) to allow only the required services and ports.
- Secrets Management: Store, inject and regularly rotate credentials, API keys and certificates through a central secrets management solution.
- Auditing & Logging: Log authentication attempts, data exchanges and errors at every integration touchpoint, centralised for security monitoring, anomaly detection and compliance.
- Vulnerability Management: Run continuous vulnerability assessments and regular penetration tests on the workloads and their interfaces, and remediate findings.
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-native-internal), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).