Temporal

Temporal is a durable workflow engine. You write Workflow code for long-running decision logic, run Worker Processes that poll for work, and let the Temporal Service persist progress. Temporal defines a Workflow Execution as durable, reliable and recoverable after failure in its Workflow Execution overview. Read Workflow orchestration first for the general pattern; this page is the concrete Temporal shape.

The Service is not where your business code runs. Temporal's Worker docs say Worker Processes poll Task Queues, execute Workflow or Activity code, and run outside the Temporal Service, while the Service orchestrates state transitions and dispatches tasks Workers. That split is why you scale your workers for CPU, I/O and credentials, while the Service owns history, task routing and timers.

Use Temporal when the workflow has multiple dependent steps, long waits, human messages, compensation, or a need to answer "what already happened?" from one history. Use Long-running tasks or a queue plus a state table when the job is small: one or two steps, short retries, simple status, no human wait and no compensation chain.

1. The Service stores progress; workers execute code

Temporal's server has four independently scalable services: Frontend for API routing and authorization, History for Workflow mutable state, queues and timers, Matching for user-facing Task Queues, and the internal Worker Service for background system work Temporal Server. Persistence stores Tasks, Workflow mutable state, the History table, Namespace metadata and Visibility data. Temporal documents Cassandra, PostgreSQL and MySQL as tested persistence databases, with SQLite meant for development and testing rather than production Persistence.

A Namespace is the isolation boundary for Workflow IDs, Task Queues, retention and access configuration. Temporal says Task Queues and Workflow Executions belong to a Namespace, and a Workflow ID is unique inside that Namespace Namespaces. A Task Queue is a lightweight queue that one or more workers poll over synchronous RPC; Temporal notes that workers poll only when they have spare capacity and that Workflow and Activity Tasks persist in a Task Queue if a worker goes down Task Queues.

2. Event History is the source of truth

Temporal tracks each Workflow Execution by appending Events such as Activity scheduled, Timer fired, Signal received and Workflow completed. Its Event History docs call this an append-only, durably persisted log that lets the application state survive crashes and also acts as an audit log Events and Event History. When a worker resumes a Workflow, it replays the history and compares generated Commands with existing Events Workflow Execution.

That replay model creates the main rule: Workflow code must be deterministic. Temporal states that Workflow code must make the same Workflow API calls in the same sequence for the same input, and that non-deterministic work such as API calls, database queries and LLM calls should go in Activities Workflow Definition. Use workflow-safe time and random APIs. Do not branch on local wall-clock time inside workflow code.

3. Activities are the side-effect boundary

An Activity is a normal function for one well-defined action, such as calling a payment API or writing a derived file Activity Definition. Temporal recommends idempotent Activities because completed Activities do not rerun during replay, but a worker can crash after the external side effect and before the completion is recorded, causing a retry Activity idempotency. Link this directly to Idempotency: the Activity needs a business key that makes a repeated call safe.

Activities retry by default. Temporal documents the default Retry Policy as an initial interval of 1 second, a 2.0 backoff coefficient, a maximum interval of 100 seconds, unlimited maximum attempts and no non-retryable errors Retry Policies. Activity timeouts decide how failures are detected: Start-To-Close bounds a single attempt, Schedule-To-Close bounds the whole Activity Execution including retries, and Heartbeat Timeout detects a long-running Activity that stopped heartbeating Detecting Activity failures.

4. Messages, timers and code changes are first-class

Temporal has three workflow message types. Signals are asynchronous writes, Queries read current state without recording an Event, and Updates are synchronous writes that can return a result; Temporal's feature guide shows the differences in a comparison table Workflow message passing. These are the clean way to model approval, cancellation, progress reads and admin intervention without inventing a side channel.

Timers are durable. The TypeScript timer docs say a Workflow can sleep for months, timers are persisted, and the worker process is not tied up during the wait Timers. Running workflows also need a change plan. Temporal's TypeScript versioning docs warn that adding, removing or reordering await calls on command-producing APIs such as Activities and timers can cause replay problems, and recommend Worker Versioning or Patching Versioning.