Temporal Workflow

The Temporal model cleanly separates deterministic workflow logic from non-deterministic activity implementations. A Workflow defines the orchestration logic—the sequence, conditions, and retries for tasks. An Activity is a single unit of work that interacts with the outside world, such as calling an API, querying a database, or sending an email. This separation is critical for reliability; if an Activity fails, the workflow's state is preserved and it can retry the Activity based on a defined policy.

• Workflow Function: Defines the orchestration (the 'what' and 'when').
• Activity Function: Defines the execution (the 'how') of a single task.
• Decoupled Failure Domains: Activity failures do not corrupt workflow state.

Temporal provides first-class, configurable retry policies and timeouts for both Activities and Child Workflows. Developers declaratively set maximum attempts, backoff intervals, and expiration windows. The system automatically manages retry scheduling and failure escalation. This eliminates the need for bespoke retry logic and ensures robust handling of transient failures.

• Exponential Backoff: Configurable initial interval and backoff coefficient.
• Jitter: Optional randomization to prevent thundering herds.
• Comprehensive Timeouts: Start-to-close, schedule-to-start, and heartbeat timeouts.

Temporal uses an event sourcing architecture. Instead of storing the current state of a workflow, it records an append-only log of all events that have occurred (e.g., WorkflowStarted, ActivityTaskScheduled, TimerFired). The current state is derived by replaying these events through the workflow code. This enables powerful features like deterministic replay for debugging and seamless versioning of workflow definitions.

• Immutable Event History: The single source of truth for workflow state.
• State Reconstruction: Workers rebuild state by replaying events.
• Debugging: Any execution can be exactly replayed in a debugger.

Workflows can schedule delays or time-based triggers using durable timers. Unlike sleep() in standard code, which blocks a process, a Temporal timer is an asynchronous command that is persisted to the event history. The workflow can continue processing other events or be fully evicted from memory; the Temporal service will wake it up when the timer fires. This enables long delays (e.g., 'send a reminder email in 7 days') without consuming compute resources.

• Non-Blocking: Workflow execution is suspended, not the host process.
• Durable: Timers survive process and host failures.
• Scalable: Millions of timers can be managed efficiently by the Temporal service.

A property of an operation where performing it multiple times has the same effect as performing it once. This is a critical requirement for activities in a fault-tolerant system where retries are inevitable.

• Why It Matters: Temporal's built-in retry logic and recovery from failures can lead to activity code being executed more than once.
• Implementation: Achieved using unique idempotency keys, conditional checks, or designing operations to be naturally idempotent (e.g., SET status = 'processed').

A computational model consisting of a finite number of states, transitions between those states triggered by events, and associated actions. It provides a formal way to define complex business logic and lifecycle management.

• Orchestration Use: Workflows are often state machines (e.g., order status: Pending → Paid → Fulfilled → Shipped).
• Temporal Model: While Temporal workflows are code-based, they implicitly define a state machine. Frameworks like AWS Step Functions explicitly use state machine definitions (ASL) as their primary model.

A finite directed graph with no cycles, used to model dependencies between tasks. In orchestration, nodes represent tasks and edges represent execution order dependencies.

• Primary Use: Defining static, dependency-driven workflows where tasks cannot create circular dependencies.
• Example Systems: Apache Airflow and Kubeflow Pipelines use DAGs as their core abstraction.
• Contrast with Temporal: Temporal workflows are defined imperatively in code, which can express dynamic, cyclic, and long-running logic that is difficult to model in a static DAG.

An operation that semantically undoes the effects of a previously committed local transaction within a larger business process. It is the rollback mechanism in the Saga pattern.

• Nature: It is a business-level undo, not a database rollback (e.g., "Cancel Reservation" is the compensating transaction for "Make Reservation").
• Temporal Implementation: Built into the programming model, where activities can fail and workflows can execute cleanup or compensation logic using try-catch blocks and explicit compensation steps.