Temporal’s power lies in its ability to reliably execute workflows even in the face of failures. At the core of this model are three main entities: Workflow, Activity, and Event History. Each plays a distinct role in ensuring resilience and correctness.
A Workflow defines the business process you want to run.
For example: check user balance → subtract money from sender’s account → add money to receiver’s account.
Deterministic: Every step in a workflow must always produce the same output for the same input.
Why this matters: Temporal relies on Workflow Replay to recover from interruptions. Replay re-executes workflow code against the recorded Event History to resume execution. If a workflow weren’t deterministic, replaying it could lead to inconsistent or incorrect results.
An Activity represents the actual work your system performs.
Examples: making an API call, writing to a database, or processing data.
Can fail: Because Activities often interact with external systems, they are naturally prone to failure. Temporal automatically retries failed Activities.
Should be idempotent: Since retries may happen multiple times, Activities must be idempotent. This ensures that repeated executions won’t cause incorrect states or unintended side effects.
The Event History is the durable record of workflow execution. It captures every important detail: workflow decisions, activity inputs and outputs, and state changes.
Durable: Event History is stored in a way that survives crashes and outages.
Why this matters: When a workflow is paused or fails, Temporal consults the Event History to rebuild its state and continue execution without losing progress.
— Aug 9, 2025
Made with ❤ and at Earth.