Practice: Durable workflows and event-driven services with Temporal
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: Temporal · Temporal is the tool the lesson is built around, and its local development server lets you practise durable execution, replay, activity retries and message passing end to end on a laptop. · Alternatives: Apache Airflow and Dagster schedule batch DAGs rather than long-lived event-driven processes; AWS Step Functions is a managed state machine defined in JSON rather than code; Argo Workflows runs container steps on Kubernetes without replay-based durability; Kafka or RabbitMQ with hand-written consumers gives messaging but leaves state, retries and timers to you.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Install Python 3.9 or newer, create a virtual environment and install the Temporal Python SDK by following the Python quickstart.
The whole path is written against one SDK, and the Python SDK is the one most ML platform code already sits next to.
Explained in: Quickstarts | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: Importing the temporalio package in the virtual environment succeeds without an error.
2. Install the Temporal CLI and start the local development server, then open its Web UI in a browser.
The development server is a single binary holding the whole Temporal Service, so no cloud account or cluster is needed to practise.
Explained in: Quickstarts | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The Web UI loads and shows the default namespace with an empty list of Workflow Executions.
3. Create a project folder with four separate files: workflow definitions, activity definitions, a worker program and a client starter script.
A Temporal Application is split into these parts, and keeping them apart from the start makes the determinism boundary between workflows and activities visible.
Explained in: What is Temporal? | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The folder holds the four files and each can be imported without an error.
Steps
1. Run the quickstart hello-world workflow end to end: start the worker, start the workflow from the client script and read the result.
A first run proves the server, the worker and the client can talk to each other before you write anything of your own.
Explained in: Quickstarts | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The client prints the workflow result and the Web UI lists one Workflow Execution with status Completed.
2. Write a model promotion workflow that calls three activities in order: validate the model, run an evaluation, then publish it to a registry stub.
A workflow is ordinary code describing the steps of a long-running process, and a promotion pipeline is the kind of ML platform process Temporal fits best.
Explained in: Temporal Workflow | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: Starting the promotion workflow completes and the Web UI shows the three activities scheduled and completed in order.
3. Start two worker processes that poll the same named task queue, then start several promotion workflows and note which worker identity picks up each task.
Workers are your own processes that run workflow and activity code, and scaling means adding processes on the same task queue rather than changing the server.
Explained in: What is a Temporal Worker? | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The Web UI shows both worker identities polling the task queue and tasks handled by each of them.
4. Start a promotion workflow while no worker is running, watch it stay in Running, then start a worker and watch it proceed.
The Matching Service holds tasks in task queues until a worker polls, which is why the server never calls your code and workers can sit inside a private ML network.
Explained in: Temporal architecture | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The execution stays Running with a scheduled workflow task and no progress until the worker starts, then completes.
5. Query the full Event History of one finished promotion workflow in the Web UI and with the CLI, and match each event to a line of your workflow code.
The Event History is the durable record of everything the workflow did, and reading it is the main debugging skill for Temporal.
Explained in: Events and Event History | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: You can point at the events for the workflow start, each activity being scheduled, started and completed, and the workflow completion.
6. Run a promotion workflow with a slow evaluation activity, kill the worker process in the middle, then restart it and watch the workflow resume.
Durable execution means the restarted worker rebuilds workflow state by replaying the history instead of re-running completed steps.
Explained in: Temporal Workflow | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The workflow completes after the restart and the validate activity appears only once in the Event History.
7. Configure a start-to-close timeout, a retry policy and a heartbeat timeout on the evaluation activity, make it fail twice and then stall, and pass an idempotency key to the publish activity.
Side effects live in activities, which the platform retries and times out according to policy, so each activity must be safe to run more than once.
Explained in: Events and Event History | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The history shows the activity attempt count rising, a heartbeat timeout failure recorded, and the registry stub holds one published entry despite retries.
8. Write a signal that delivers a human approval, a query that returns the current promotion stage and an update that changes the target environment and returns the validated value.
Signals, queries and updates turn a workflow into an event-driven service, and each suits a different kind of request: write, read, or read and write.
Explained in: Temporal Workflow message passing - Signals, Queries, & Updates | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The workflow waits until the approval signal arrives, the query returns the stage without adding events to the history, and the update returns its result to the caller.
9. Start the development server with a database file so state persists, restart the server while a workflow waits for approval, then compare the histories of an approved run and a rejected run.
The persistence layer is what makes histories survive a server restart, and comparing two histories side by side shows exactly where runs diverged.
Explained in: Temporal architecture | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: After the server restart the waiting workflow is still listed as Running, and you can name the first event at which the two runs differ.
10. Create a non-deterministic change by adding a new activity before the evaluation step while a workflow is waiting for approval, observe the failure, then fix it with a patch.
Replay requires workflow code to issue the same commands as the history recorded, so changes to running workflow code must be versioned.
Explained in: Temporal Workflow Definition | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The unpatched change produces a non-determinism error on the workflow task, and with the patch the old execution completes while new executions run the new activity.
11. Reproduce past executions by downloading their Event Histories as JSON and writing a replay test that runs them against the current workflow code in a pinned environment such as a CI job.
Replaying saved histories in automation catches non-deterministic changes before a deploy rather than in running workflows.
Explained in: Events and Event History | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The replay test passes on the patched code and fails when the patch is removed.
12. Deploy a self-hosted Temporal Service locally with containers and PostgreSQL as the database, point your workers and client at it, and run the promotion workflow there; Temporal Cloud is paid, so this local stack is the substitute.
Production runs the server as separate services with a real database and workers deployed apart from it, which the single-binary development server hides.
Explained in: Temporal Platform production deployments | Temporal Documentation (docs.temporal.io), checked 2026-10-11
Done when: The promotion workflow completes against the containerised service and its history is still there after the containers are restarted.
Back to Durable workflows and event-driven services with Temporal