Temporal Workflow

The defining feature of a Temporal workflow is its durable execution. The engine persists the full execution state—including local variables, the program counter, and thread stacks—to a database after every step. This allows workflows to survive process crashes, host failures, and code deployments without losing progress. Execution can resume from the last persisted state, making workflows inherently resilient and capable of running for days, months, or even years.

• State Persistence: Workflow state is automatically checkpointed.
• Failure Recovery: Processes can be restarted on any available worker.
• Long-Running Logic: Enables business processes like order fulfillment or multi-day data pipelines.

A Temporal workflow's logic must be deterministic, meaning that given the same initial state and event history, it will always execute the same sequence of instructions. This determinism is what enables reliable state recovery and replay. To enforce this, workflow code is restricted from performing non-deterministic operations like generating random numbers or accessing the system clock directly. Instead, these operations are performed inside Activities.

• Core Constraint: Code must produce identical execution paths on replay.
• Non-Deterministic Prohibitions: No I/O, network calls, or randomness in workflow functions.
• Activity Abstraction: All side effects and external calls are delegated to Activities.

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 design pattern for managing long-running, distributed transactions by breaking them into a sequence of local transactions. Each local transaction has a corresponding compensating transaction to roll back the overall process in case of failure, ensuring eventual consistency without traditional distributed locks.

• Key Use Case: E-commerce order processing involving inventory, payment, and shipping services.
• Contrast with ACID: Provides a practical alternative to two-phase commit in microservices.
• Temporal Implementation: Natively supported through durable workflow execution and activity compensation logic.

An architectural pattern where the state of an application is derived from an immutable, append-only log of events. Instead of storing the current state, the system persists the sequence of state-changing events, which can be replayed to reconstruct any past state.

• Core Benefit: Provides a complete audit trail and enables deterministic replay for debugging.
• Relation to Temporal: Temporal's event history is a form of event sourcing, where workflow state is rebuilt by replaying activity completions, timer firings, and signals from its durable log.

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.