Architecture
An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes.
Full FlowZap Code
Trigger { # Trigger
n1: circle label:"Start Execution"
n2: rectangle label:"API Gateway / EventBridge"
n3: rectangle label:"Invoke Step Function"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="StartExecution"]
n3.handle(bottom) -> StateMachine.n4.handle(top) [label="Input JSON"]
}
StateMachine { # AWS Step Functions
n4: rectangle label:"Validate Input (Task)"
n5: diamond label:"Order Type?"
n6: rectangle label:"Standard Order Path"
n7: rectangle label:"Express Order Path"
n8: rectangle label:"Parallel Processing"
n9: rectangle label:"Wait for Approval"
n10: diamond label:"Approved?"
n11: rectangle label:"Execute Final Step"
n12: rectangle label:"Compensation Rollback"
n13: circle label:"End State"
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Standard"]
n5.handle(bottom) -> n7.handle(top) [label="Express"]
n6.handle(right) -> n8.handle(left)
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Map State"]
n9.handle(right) -> n10.handle(left) [label="Callback"]
n10.handle(right) -> n11.handle(left) [label="Yes"]
n10.handle(bottom) -> n12.handle(top) [label="No"]
n11.handle(right) -> n13.handle(left)
n12.handle(right) -> n13.handle(left) [label="Rolled Back"]
n8.handle(bottom) -> Lambdas.n14.handle(top) [label="Invoke"]
}
Lambdas { # Lambda Functions
n14: rectangle label:"Payment Lambda"
n15: rectangle label:"Inventory Lambda"
n16: rectangle label:"Notification Lambda"
n17: rectangle label:"Error Catcher Lambda"
n14.handle(right) -> n15.handle(left) [label="Charge"]
n15.handle(right) -> n16.handle(left) [label="Reserve"]
n16.handle(top) -> StateMachine.n9.handle(bottom) [label="Result"]
n17.handle(top) -> StateMachine.n12.handle(bottom) [label="Error Info"]
}
Why This Workflow?
Coordinating multi-step serverless workflows with direct Lambda-to-Lambda calls creates brittle chains that are hard to monitor and debug. Step Functions provide visual workflow orchestration with built-in state management, error handling, retries, and human approval gates—all without writing coordination code.
How It Works
- Step 1: An API Gateway or EventBridge trigger starts the Step Function execution with input JSON.
- Step 2: The state machine validates input and routes to the appropriate processing path.
- Step 3: Parallel states execute multiple Lambda functions simultaneously.
- Step 4: Wait states pause execution for human approval callbacks.
- Step 5: Error catchers route failures to compensation Lambda functions for rollback.
- Step 6: The final state returns the execution result or marks the saga as rolled back.
Alternatives
Direct Lambda chaining is simpler but lacks visibility and error handling. Temporal.io provides more powerful workflow orchestration but requires server management. This template shows AWS-native serverless orchestration.
Key Facts
| Template Name | Serverless Step Functions Orchestration Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A serverless event processing architecture diagram with S3, DynamoDB Streams, API Gateway, and CloudWatch triggers invoking Lambda functions, orchestrated by Step Functions with fan-out via SQS and dead letter queue error handling. This template shows how to build complex event processing pipelines entirely from managed serverless components, with no servers to provision or manage. Ideal for data processing workflows that need elastic scaling and built-in fault tolerance.
Architecture
A multi-cloud serverless architecture diagram with DNS-based traffic routing between AWS and Azure regions, automatic failover on health check failures, and bi-directional data replication with conflict resolution across cloud providers. This template models the multi-cloud strategy for maximum availability and vendor independence, using serverless services from both AWS (Lambda, DynamoDB) and Azure (Functions, Cosmos DB). Critical for enterprises requiring cloud provider redundancy.
Architecture
A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.
Architecture
A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.
Architecture
A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario.
Architecture
A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load.