Integration Workflow & Orchestration (External)
Problem
A business process is started by, or has to call, systems owned by partners and third parties, with traffic crossing the public internet in both directions, so inbound calls must stop at a WAF-protected edge API gateway and each partner must authenticate (OAuth 2.0 or mTLS). It also runs across several internal microservices for minutes or days, so teams must keep its state, recover from failures in systems they don't control, and trace each instance end to end.
Solution
Inbound requests and events land on an API Gateway or event ingestion service in the Public Subnet (Perimeter), behind a WAF, which authenticates the caller (OAuth 2.0 client credentials or mTLS) and terminates TLS. A cloud-native Workflow Orchestration Engine in a private subnet then runs the process, calling internal Backend Workloads and a decision engine. Outbound calls, by API, event stream or message broker, leave through a Managed NAT/Egress Gateway with FQDN allow-listing.
Cloud Paradigm
- Serverless Workflow Orchestration
- Event-Driven Architecture
- Microservices Orchestration and Choreography
- API-Led Connectivity
- Zero Trust Architecture
- Distributed State Management
- Resilience Engineering (e.g., Saga Pattern for distributed transactions)
Solution Flow
Inbound Flow (External Initiated Workflow):
- External System: A third-party system sends a request or event over the Public Internet to trigger a business process.
- Edge Protection (WAF): At the public-facing cloud edge, a Web Application Firewall (WAF) inspects traffic for malicious activity and enforces basic traffic policies.
- API Gateway / Event Ingestion: The request reaches an API Gateway (synchronous calls) or an Event Ingestion Service / Message Queue (asynchronous events), which authenticates the caller, terminates TLS and may transform the payload.
- Workflow Orchestration Engine: The gateway or ingestion service starts a new instance of the Workflow Orchestration Engine, typically in a Private Subnet (Workloads).
- Internal Microservices & Decision Engine: The engine executes predefined steps, invoking internal Backend Workloads (microservices) and possibly a Business Rules/Decision Engine.
- Response / Callback: A synchronous response returns through the API Gateway; for asynchronous flows, the workflow may send a completion event or callback to the external system.
Outbound Flow (Internal Workflow Initiating External Interaction):
- Workflow Orchestration Engine: The engine reaches a step that needs an external system (e.g., calling a partner API, sending a notification).
- Internal Microservice / API Gateway: It invokes an internal Backend Workload or an API Gateway proxy for external connectivity, which handles data mapping, protocol translation or aggregation.
- Egress Gateway / Managed NAT: Because workloads sit in Private Subnets, outbound traffic passes through a Managed NAT/Egress Gateway that enforces FQDN allow-listing, performs network address translation and applies egress edge protection (WAF) if configured.
- External Target: The partner system or external data source receives the request from a static, allow-listed cloud egress IP.
- External Response / Callback: The external system returns a synchronous response to the Egress Gateway/API Gateway, or sends an asynchronous callback or event that may trigger another inbound flow.
When to Use
- Long-running processes (minutes to days) span multiple internal microservices and must survive restarts, so they need durable state and resumability.
- Processes cross organisational boundaries, calling partner APIs or ingesting external events, and need static allow-listed egress IPs and FQDN-based outbound controls.
- Distributed transactions need compensation logic (Saga patterns), automated retries and circuit breakers to reach eventual consistency across services you don't fully control.
- Workflows include human-in-the-loop steps, such as approvals or manual data entry, that pause execution indefinitely.
- Auditors or operators need end-to-end observability and version-controlled, declarative process definitions for compliance.
When NOT to Use
- The interaction is a single synchronous request/response with no multi-step state. A direct API Gateway call or point-to-point integration is simpler and cheaper.
- Processing is pure event-driven fan-out with no ordering or state dependencies; a plain message broker or event bus suffices.
- On latency-critical paths, the engine's state persistence and hop count would break sub-second SLAs.
- Simple ETL or batch data movement is better served by a scheduled data pipeline.
- Services should react to events autonomously, and central coordination would create a bottleneck or single point of governance. Prefer choreography.
Trade-offs
- Durable state and fault-tolerant resumption vs the cost of running and scaling a stateful engine and its backing store.
- Central visibility and version-controlled process definitions vs the engine becoming a bottleneck and single point of failure.
- Reliable cross-boundary integration via Saga compensation vs authoring and testing compensation logic for every distributed step.
- Secure, policy-enforced egress through NAT and FQDN allow-listing vs extra hops, latency and perimeter configuration upkeep.
- End-to-end tracing across internal and external calls vs the instrumentation and telemetry-storage overhead.
Illustrative Scenario
A hypothetical scenario showing how the pattern applies. Not a client case study.
Think of a hypothetical freight forwarder that orchestrates customs clearance for inbound ocean containers. When a shipping line sends an arrival notification over the public internet, a WAF inspects the message and an Event Ingestion Service authenticates the carrier. The carrier never reaches the private subnet directly. Only then does a new Workflow Orchestration Engine instance start inside a private subnet. The workflow invokes internal document-validation and HS-code classification microservices, then asks a decision engine for duty rates and inspection routing. High-value declarations pause at a human-in-the-loop approval task until a customs broker signs off. After approval, an outbound step submits the entry to the national customs authority's API through a Managed NAT gateway, which presents a static, allow-listed egress IP and applies FQDN restrictions. The authority's asynchronous release callback comes back as an inbound event and moves the workflow on to release the container. OpenTelemetry traces record every hop for compliance audits.
Additional Details
- Workflow Definition: Define processes in declarative, human-readable languages (e.g., YAML, JSON-based DSLs) or graphical interfaces, so they are auditable and version-controlled.
- State Persistence: The Workflow Orchestration Engine must persist the state of long-running processes so they tolerate faults and resume after interruptions.
- Error Handling & Compensation: Use automated retries with exponential backoff, circuit breakers for failing external dependencies, and compensation logic (e.g., Saga patterns) for distributed transactions.
- Human-in-the-Loop: Raise notifications or tasks in dedicated user interfaces for approvals or manual data entry, pausing the workflow until someone completes them.
- Event-Driven Integration: Use event streams and message queues to decouple steps and communicate asynchronously, for scalability and resilience.
- Observability: Collect logs, metrics (e.g., workflow execution times, task status, error rates) and distributed traces (e.g., OpenTelemetry) along the whole execution path, including internal and external calls.
- Infrastructure as Code (IaC): Manage workflow definitions, engine configuration and infrastructure as code, deployed via CI/CD pipelines.
Security Controls
- Perimeter Security: For externally triggered workflows, all inbound requests must terminate at an Edge API Gateway or message ingestion service in a Public Subnet (Perimeter), protected by a Web Application Firewall (WAF) against common vulnerabilities (e.g., OWASP Top 10) and for traffic management.
- Transport Security: Enforce Transport Layer Security (TLS 1.2 or higher) on all internal and external endpoints, including between the workflow engine, microservices and external systems.
- Authentication & Authorisation:
- For system-to-system integrations (workflow to external system, or external system to workflow), authenticate with OAuth 2.0 (Client Credentials Grant) or Mutual TLS (mTLS).
- Apply Role-Based Access Control (RBAC) to workflow execution roles, with least privilege for all internal and external resources.
- Data Encryption: Encrypt sensitive data the workflow engine processes or persists, including workflow state, at rest and in transit.
- Outbound Controls: Configure the Egress Gateway and egress edge protection (WAF) to allow workflow-initiated connections only to explicitly allow-listed external IP addresses or fully qualified domain names (FQDNs). Apply Data Loss Prevention (DLP) to sensitive outbound data where compliance requires it.
- Auditing and Logging: Log all workflow state changes, task executions and internal and external interactions, including critical security events, to a central Security Information and Event Management (SIEM) system.
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-workflow-external), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).