Temporal Durable Execution Cheat Sheet

Updated 2026-05-23

🧠Study flashcards on this topic121 cards · spaced repetition→

Temporal is an open-source durable execution platform that lets developers write reliable, long-running workflows as ordinary code, automatically persisting state and retrying failures across process crashes and hardware outages. It solves the distributed-systems reliability problem — error handling, retries, timeouts, and state management — so application code can focus on business logic rather than fault-tolerance plumbing. The key mental model: a Temporal Workflow is a crash-proof function that can run for seconds or years, while Activities are the side-effectful steps (API calls, database writes) that the Workflow orchestrates and that can be retried independently.

What This Cheat Sheet Covers

This topic spans 17 focused tables and 130 indexed concepts, 121 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Architecture and ComponentsTable 2: Workflow FundamentalsTable 3: ActivitiesTable 4: Task Queues and WorkersTable 5: Workflow Messaging — Signals, Queries, and UpdatesTable 6: Retries, Timeouts, and Failure HandlingTable 7: Durable Timers, Sleeps, and SchedulesTable 8: Child Workflows and Continue-As-NewTable 9: Workflow Versioning and DeploymentTable 10: Saga Pattern and Compensating TransactionsTable 11: Search Attributes and VisibilityTable 12: Namespaces, Multi-Tenancy, and Deployment OptionsTable 13: Encryption, Data Converters, and PII HandlingTable 14: Observability — Metrics, Tracing, and Web UITable 15: Comparing Temporal to Other OrchestratorsTable 16: Common Anti-PatternsTable 17: Scaling and Operational Patterns

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Architecture and Components

Temporal's architecture separates the coordination plane (the Temporal Service) from the execution plane (Workers). Understanding how these three roles — Service, Worker, and Client — interact is the foundation for everything else in the platform.

Concept	Example	Description
Temporal Service	Temporal Cloud or self-hosted cluster	• The central coordination layer that persists Event History, schedules Tasks, and manages Namespace state • Workers and Clients connect to it via gRPC
Worker Process	`w := temporal.NewWorker(c, "my-queue", opts)`	A long-running process that polls Task Queues for Workflow and Activity Tasks, executes them, and reports results back to the Service.
Temporal Client	`c, _ := client.Dial(client.Options{})`	SDK object used by application code to start Workflow Executions, send Signals, issue Queries, and run Updates against the Temporal Service.
Workflow Execution	A running instance of `OrderWorkflow` for order #42	• The durable, stateful execution unit — uniquely identified by Namespace + Workflow ID + Run ID • survives Worker crashes by replaying Event History
Activity Execution	`executeActivity(chargeCard, input, opts)`	• A single invocation of an Activity function • encapsulates side-effectful, non-deterministic code (API calls, DB writes) outside the replay path
Event History	`WorkflowExecutionStarted → ActivityTaskScheduled → ActivityTaskCompleted…`	• An append-only log of every Command and Event in a Workflow Execution • the source of truth used to replay and reconstruct state after any failure
Workflow Task	Worker pulls a `PollWorkflowTaskQueue` response	• A unit of work dispatched to a Worker to advance a Workflow Execution • the Worker re-executes Workflow code (replay) and emits new Commands
Activity Task	Worker pulls a `PollActivityTaskQueue` response	• A unit of work dispatched to a Worker to execute a single Activity function • persisted in the Task Queue until a Worker picks it up
Namespace	`temporal operator namespace create --retention 30d my-ns`	• An isolation boundary for Workflow Executions, Task Queues, and Search Attributes • enforces data retention and access control independently
Temporal CLI	`temporal workflow start --type OrderWorkflow --task-queue orders`	• Command-line tool for managing Workflows, Namespaces, Schedules, and Search Attributes • also used to run a local dev server

Table 2: Workflow Fundamentals

A Workflow Definition is an ordinary function or class method that must obey determinism rules so the Temporal Service can replay it faithfully. These fundamentals govern what is and is not safe to write inside Workflow code.

Concept	Example	Description
Workflow Definition	`@workflow.defn` `class MyWorkflow:` `@workflow.run` `async def run(self, name: str) -> str: ...`	• The source code (function or class method) that defines a Workflow • compiled once but executed many times during replay — must be deterministic.

The rest of this section is part of the full cheat sheet

Table 3: Activities

Activities are the building blocks for all side effects in Temporal. They run outside the determinism constraint, support automatic retry, and interact with the outside world on behalf of the Workflow.

Concept	Example	Description
Activity Definition	`@activity.defn` `async def charge_card(amount: int) -> str: ...`	• An ordinary function decorated to be registered with a Worker • can call external APIs, databases, or any non-deterministic code freely

The rest of this section is part of the full cheat sheet

Table 4: Task Queues and Workers

Task Queues are the lightweight dispatch mechanism connecting the Temporal Service to Workers. Understanding polling, concurrency slots, and Task Routing is essential for scaling worker fleets.

Concept	Example	Description
Task Queue	`"payment-service-queue"`	• A named, dynamically allocated queue holding Workflow Tasks and Activity Tasks • created on demand, no explicit registration required

The rest of this section is part of the full cheat sheet

Table 1: Core Architecture and Components

Concept	Example	Description
Temporal Service	Temporal Cloud or self-hosted cluster	• The central coordination layer that persists Event History, schedules Tasks, and manages Namespace state • Workers and Clients connect to it via gRPC
Worker Process	`w := temporal.NewWorker(c, "my-queue", opts)`	A long-running process that polls Task Queues for Workflow and Activity Tasks, executes them, and reports results back to the Service.
Temporal Client	`c, _ := client.Dial(client.Options{})`	SDK object used by application code to start Workflow Executions, send Signals, issue Queries, and run Updates against the Temporal Service.
Workflow Execution	A running instance of `OrderWorkflow` for order #42	• The durable, stateful execution unit — uniquely identified by Namespace + Workflow ID + Run ID • survives Worker crashes by replaying Event History
Activity Execution	`executeActivity(chargeCard, input, opts)`	• A single invocation of an Activity function • encapsulates side-effectful, non-deterministic code (API calls, DB writes) outside the replay path
Event History	`WorkflowExecutionStarted → ActivityTaskScheduled → ActivityTaskCompleted…`	• An append-only log of every Command and Event in a Workflow Execution • the source of truth used to replay and reconstruct state after any failure
Workflow Task	Worker pulls a `PollWorkflowTaskQueue` response	• A unit of work dispatched to a Worker to advance a Workflow Execution • the Worker re-executes Workflow code (replay) and emits new Commands
Activity Task	Worker pulls a `PollActivityTaskQueue` response	• A unit of work dispatched to a Worker to execute a single Activity function • persisted in the Task Queue until a Worker picks it up
Namespace	`temporal operator namespace create --retention 30d my-ns`	• An isolation boundary for Workflow Executions, Task Queues, and Search Attributes • enforces data retention and access control independently
Temporal CLI	`temporal workflow start --type OrderWorkflow --task-queue orders`	• Command-line tool for managing Workflows, Namespaces, Schedules, and Search Attributes • also used to run a local dev server

Table 2: Workflow Fundamentals

Concept	Example	Description
Workflow Definition	`@workflow.defn` `class MyWorkflow:` `@workflow.run` `async def run(self, name: str) -> str: ...`	• The source code (function or class method) that defines a Workflow • compiled once but executed many times during replay — must be deterministic.

Table 3: Activities

Concept	Example	Description
Activity Definition	`@activity.defn` `async def charge_card(amount: int) -> str: ...`	• An ordinary function decorated to be registered with a Worker • can call external APIs, databases, or any non-deterministic code freely

Table 4: Task Queues and Workers

Task Queues are the lightweight dispatch mechanism connecting the Temporal Service to Workers. Understanding polling, concurrency slots, and Task Routing is essential for scaling worker fleets.

Concept	Example	Description
Task Queue	`"payment-service-queue"`	• A named, dynamically allocated queue holding Workflow Tasks and Activity Tasks • created on demand, no explicit registration required