Master Workflow Orchestration Patterns

This skill guides Temporal workflow architecture for multi-step processes that span services, machines, and databases. It addresses long-running business processes, entity lifecycles, failure recovery, infrastructure automation, and human approvals. The central design boundary puts deterministic coordination in workflows and external interactions in activities.

Workflows decide which steps run, coordinate children, manage timeouts, and handle compensation. Activities perform API requests, database writes, and notifications. Because activities can run repeatedly after failures, their effects need idempotency. Implementation strategies include deduplication keys, unique constraints, upserts, and tracking processed request identifiers.

Use it for processes that must preserve progress and resume after failures, such as bookings, orders, inventory, or approvals. Simple CRUD can use direct APIs; stateless request-response work belongs in ordinary APIs; pure data pipelines may fit batch tools; real-time streams may fit event processors instead.

The patterns require project-specific goals, constraints, inputs, and verification. They are architectural guidance rather than a deployed workflow implementation. SDK language and installed version matter, particularly when changing code while existing executions are still active. Replay old histories before deployment instead of assuming a new implementation is compatible.

Inputs include process steps, external effects, compensation behavior, timeouts, failure classes, and operational limits. Outputs are workflow and activity boundaries, selected coordination patterns, retry and heartbeat policies, versioning decisions, and verification steps. A saga registers compensation before attempting the corresponding action:

For each step:
  1. Register compensation BEFORE executing
  2. Execute the step (via activity)
  3. On failure, run all compensations in reverse order (LIFO)

Other patterns include an entity workflow that accepts signals and answers state queries, bounded fan-out through child workflows, and asynchronous callbacks that resume coordination after an external response. Large task sets should be decomposed rather than allowed to grow one workflow without bounds.

Event History supports replay and recovery. Workflow logic must avoid direct network or file I/O, ordinary system time, uncontrolled randomness, global state, and nondeterministic libraries. Temporal's workflow time and random APIs provide deterministic alternatives. External work stays in activities.

Retry policies need intervals, backoff, delay caps, attempt limits, and a distinction between transient and permanent failures. Long activities use heartbeats with progress information and appropriate timeouts. Python versioning uses workflow.patched and workflow.deprecate_patch; other SDKs differ. Alternatives include a new workflow type or backward-compatible code.

Operational guidance covers execution duration, activity failures, retries, pending counts, worker scaling, task queue partitioning, payload limits, and time-skipping tests. These checks help validate recovery behavior beyond a successful first execution.