$ loading_
Design and assess workflow orchestration patterns, state machines, and failure handling.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "system-type-workflow-orchestration" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/system-type-workflow-orchestration/SKILL.md 2. Save it as ~/.claude/skills/system-type-workflow-orchestration/SKILL.md 3. Reload skills and tell me it's ready
I am designing a business flow with ordering, payment, inventory, shipping, and notifications. Based on step count, failure handling, observability, and team coordination, decide whether to use orchestration or choreography and explain the trade-offs.
A recommendation with suitability criteria, risks, and why the alternative is less appropriate.
Design a state machine for an order processing workflow, including main states, valid transitions, terminal states, and timeout policies for every non-terminal state to prevent illegal transitions.
A structured state machine design with states, triggers, timeouts, and terminal conditions.
Assess the design of a long-running workflow system, focusing on retry hierarchies, timeout hierarchies, human approval gates, compensation logic, and common failure modes, and identify anti-patterns.
A risk list, design flaws, and improvement suggestions to judge readiness for launch or refactoring.
Developers or product managers can use it when planning complex flows with branching, retries, timeouts, and compensation to decide whether orchestration fits and to structure the overall process.
Teams can use these patterns and failure analyses when selecting or reviewing workflow engines and job orchestrators to check observability, failure handling, and architectural risks.
When a process has clear phases and legal transition rules, the state machine approach helps define states, transitions, terminal states, and timeout policies to reduce stuck or invalid executions.
The document explains workflow orchestration systems by comparing orchestration and choreography, including when each approach fits, their trade-offs, and common anti-patterns. It highlights why centralized orchestration is often easier to debug and govern in complex multi-step flows. It also covers state machine modeling, stressing explicit transitions, terminal states, and timeout policies for every non-terminal state to reduce failure risk in long-running processes.
Patterns, failure modes, and anti-patterns for long-running workflow and process orchestration systems.
Orchestration. A central coordinator owns the workflow definition and explicitly directs each step. The coordinator calls services, waits for results, handles failures, and decides what happens next. The entire flow is visible in one place. When to use. Complex multi-step processes (5+ steps). Flows with conditional branching, retries, timeouts, or compensation logic. When you need a single place to understand what the process does. When you need to answer "where is this order in the pipeline?" without querying every service. When to avoid. Simple event reactions (service A publishes, service B reacts). When the coordinator becomes a bottleneck or single point of failure you can't tolerate. When teams owning individual steps need to evolve independently without touching the orchestrator.
Choreography. Each service listens for events and decides what to do next. No central coordinator. The process is emergent from the event chain. When to use. Loosely coupled domains where services genuinely don't need to know about each other. Simple fan-out patterns (order placed → send email, update analytics, reserve inventory). When the number of steps is small (≤3) and failure handling is straightforward. When to avoid. When you catch yourself drawing the event flow on a whiteboard and it takes more than 60 seconds to explain. When debugging requires tracing events across 6 services to figure out why an order is stuck. When compensation logic is non-trivial — choreographed compensation is a nightmare to reason about.
The honest tradeoff. Choreography feels elegant and decoupled until something goes wrong. Orchestration feels heavy and centralized until you need to debug a production incident at 2am. Most teams that start with choreography for complex flows end up building an ad-hoc orchestrator anyway — they just don't call it that, and it's worse than a purpose-built one.
What it is. Model workflow as a finite set of states with explicit transitions between them. Each transition has a trigger (event, condition, timeout) and may have side effects. When to use. Workflows with well-defined states and transitions: order processing, approval flows, document lifecycle, account provisioning. When you need to enforce that certain transitions are illegal (e.g., can't ship before payment). When auditors ask "what are all the possible states this entity can be in?" When to avoid. Workflows where the number of states explodes combinatorially (parallel execution with many branches). Purely sequential pipelines where a state machine adds ceremony without value. Key discipline. Every state machine needs an explicit terminal state and a timeout for every non-terminal state. A state machine without timeouts is a state machine that accumulates orphaned instances forever.
What it is. Model workflow as a directed acyclic graph where nodes are tasks and edges are dependencies. Tasks with no unmet dependencies can execute in parallel. When to use. Data pipelines, build systems, ETL jobs, ML training pipelines — anywhere the work is a dependency graph with parallelism opportunities. When tasks are largely independent and the critical path optimization matters. When to avoid. Workflows with cycles (approval → rejection → resubmission). Workflows where the graph shape depends on runtime results (conditional branching makes DAGs awkward). Long-running workflows with human interaction — DAG engines are typically designed for batch, not for processes that pause for days. Key systems. Airflow, Prefect, Dagster, Argo Workflows. Each has different opinions about dynamic DAGs, task isolation, and scheduling.
…
It is used to design and evaluate workflow orchestration systems, focusing on long-running processes, state machines, saga coordination, human gates, retry and timeout hierarchies, and failure mode analysis.
The document says orchestration is more suitable when flows have many steps, conditional branching, retries, timeouts, or compensation logic, and when you need a single place to understand the whole process. For simple event reactions and a small number of steps, choreography is more appropriate.
The document emphasizes explicit states and transitions, a timeout for every non-terminal state, and a clearly defined terminal state. This helps prevent workflows from hanging indefinitely or taking illegal transitions.
Design offline-first edge systems with sync, conflict handling, and weak-network resilience.
Design and assess enterprise integration patterns, legacy modernization, and orchestration strategies.
Review system designs with a seven-step method to surface risks and improvements.
Evaluate system designs through Unix/Linux principles for simplicity and composability.
Design or assess Azure system architectures, operations, and cloud service choices.
Design and assess multi-tenant SaaS architecture, isolation, billing, and resilience.
Design and evaluate event-driven, message-based, and asynchronous system architectures.
Design and evaluate real-time collaborative systems, sync flows, and failure handling.
Design and evaluate data pipelines, streaming systems, and ETL architecture patterns.
Design or evaluate web services, APIs, scalability, and reliability tradeoffs.
Design and evaluate core mechanisms, tradeoffs, and failures in distributed systems.
Structure system design discussions across architecture, tradeoffs, risks, and migration planning.