Architecture
Diagramme d'architecture d'orchestration AWS Step Functions avec des workflows de machine à états incluant des états de choix, du traitement parallèle, des patterns d'attente de callback et un rollback de compensation pour les étapes échouées. Ce modèle représente l'orchestration de workflows serverless où des processus multi-étapes complexes sont définis comme des machines à états avec gestion des erreurs et logique de retry intégrées. Critique pour les équipes construisant des workflows serverless fiables nécessitant une approbation humaine ou des processus de longue durée.
Code FlowZap complet
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"]
}
Pourquoi ce 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.
Comment ça fonctionne
- 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 | Architecture d'orchestration Step Functions serverless |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de traitement d'événements serverless avec déclencheurs S3, DynamoDB Streams, API Gateway et CloudWatch invoquant des fonctions Lambda, orchestrées par Step Functions avec fan-out via SQS et gestion des erreurs par file de lettres mortes. Ce modèle montre comment construire des pipelines de traitement d'événements complexes entièrement à partir de composants serverless managés, sans serveurs à provisionner ou gérer. Idéal pour les workflows de traitement de données nécessitant une mise à l'échelle élastique et une tolérance aux pannes intégrée.
Architecture
Diagramme d'architecture serverless multi-cloud avec routage du trafic basé sur le DNS entre les régions AWS et Azure, basculement automatique sur échec de vérification de santé et réplication bidirectionnelle des données avec résolution de conflits entre fournisseurs cloud. Ce modèle représente la stratégie multi-cloud pour une disponibilité maximale et une indépendance vis-à-vis des fournisseurs, utilisant des services serverless d'AWS (Lambda, DynamoDB) et d'Azure (Functions, Cosmos DB). Critique pour les entreprises nécessitant une redondance de fournisseur cloud.
Architecture
Diagramme d'architecture saga par orchestration avec un orchestrateur central coordonnant des transactions distribuées multi-étapes à travers les services Commande, Inventaire et Paiement, avec une chaîne de compensation dédiée pour le rollback en cas d'échec. Ce modèle représente le pattern saga basé sur l'orchestration où un coordinateur unique gère le cycle de vie de la transaction et déclenche des actions compensatoires lorsqu'une étape échoue. Essentiel pour les architectes implémentant des transactions distribuées fiables sans commit en deux phases.
Architecture
Diagramme d'architecture saga par chorégraphie où les services Commande, Paiement et Inventaire se coordonnent par événements de domaine sans orchestrateur central, chaque service publiant et s'abonnant à des événements qui font avancer la transaction ou déclenchent la compensation. Ce modèle représente l'approche saga décentralisée où les services réagissent de manière autonome aux événements, réduisant les points de défaillance uniques au prix d'une complexité accrue dans le suivi de l'état de la saga. Idéal pour les équipes préférant l'autonomie des services au contrôle centralisé.
Architecture
Diagramme d'architecture saga de réservation de voyage orchestrant les réservations de vol, d'hôtel et de location de voiture comme une seule transaction distribuée, avec compensation automatique pour annuler toutes les réservations si une étape échoue. Ce modèle représente le cas d'usage classique de saga où plusieurs services indépendants doivent tous réussir ou tous annuler, garantissant que les voyageurs ne se retrouvent jamais avec des réservations partielles. Parfait pour démontrer les patterns saga avec un scénario métier réel.
Architecture
Diagramme d'architecture de résilience par disjoncteur montrant la machine à états complète avec les états fermé, ouvert et semi-ouvert, le suivi du seuil de défaillance, le timer de récupération et les stratégies de réponse de repli pour protéger les services des défaillances en cascade. Ce modèle visualise le pattern disjoncteur en détail, incluant comment le disjoncteur transite entre les états en fonction des compteurs de succès et d'échec. Essentiel pour construire des microservices tolérants aux pannes qui se dégradent gracieusement sous charge.