workflow-orchestration-patterns

Register a compensation action before executing each step, execute steps via activities, and on failure run all compensations in reverse (LIFO) order. Compensations must be idempotent so retries are safe, and partial failures should be handled gracefully.

Workflows contain orchestration and decision logic and must be deterministic, while activities handle all external interactions like API calls and database writes. Activities can be non-deterministic, include built-in retries and timeouts, and must be idempotent.

Avoid Temporal for simple CRUD operations, pure data processing pipelines, stateless request-response APIs, and real-time streaming. Use direct API calls, Airflow, standard APIs, or Kafka for those cases respectively.

Workflows replay as state machines, so using datetime.now(), random(), threading, global state, or direct network calls breaks determinism. Use workflow.now() and workflow.random() instead, and move all external calls into activities.

Use the workflow.get_version() API to branch safely between old and new logic during replay. Alternatively, create a new workflow type and route new executions to it while old executions finish on the original code.

Use idempotency keys for deduplication, check-then-act with unique constraints, upsert operations instead of inserts, or track processed request IDs. This ensures duplicate executions from retries produce the same result as a single call.