Back
Keentune
Temporal curriculum 21 chapters
·
134 concepts
·
free
Everything the adaptive question bank can teach and test in Temporal, from foundations through advanced practice. Work through it in order, or start practising and let the questions find your level.
Start practising Temporal
New here? Read the Temporal guide
A free 17-minute primer — the mental model, the mistakes beginners make, and what to practise first.
A. Durable execution — what it is and what it replaces
•
local variables and the call stack are restored after a crash; you never checkpoint by hand
•
the hand-rolled retry loop, status column, dead-letter queue and cron scaffolding around a multi-step process
•
control flow is if , for and await , not a DAG file or a state-machine config
•
deterministic Workflow code decides; Activities perform every side effect
•
Temporal guarantees the Workflow finishes, not that a side effect happened exactly once
•
every step is a persisted round trip, so tight loops and single-digit-millisecond paths do not belong in a Workflow
B. The Temporal Service and the Client
•
the Service stores history and hands out Tasks; your Worker is the only thing holding your code
•
an API frontend, the history service that owns Execution state, and matching, which dispatches Tasks to pollers
•
one datastore holds event history, a second searchable one answers list queries
•
retention, authorization, limits and Workflow-ID uniqueness are all scoped to a Namespace
•
a closed Execution's history disappears when the Namespace retention period elapses
C. Workflows: definition, execution and identity
•
the function is the Definition; each run is an Execution with its own event history
•
a Workflow ID is unique among *open* Executions in a Namespace, which is what makes "start" idempotent
•
a retry, a cron firing, a reset or a continue-as-new produces a new Run ID under the same Workflow ID
•
AllowDuplicate, AllowDuplicateFailedOnly, RejectDuplicate and TerminateIfRunning
•
one bounds the entire chain of runs, the other bounds a single run
D. Determinism — the constraint everything rests on
•
re-executing the code against recorded history must produce the same commands in the same order
•
the host clock differs on every replay; only the SDK's Workflow clock is safe to read
•
a language RNG returns a different value on replay; use the SDK's seeded random
•
a freshly generated identifier differs per replay; take it from an Activity or the SDK's deterministic helper
•
HTTP calls, file reads, database queries and environment reads belong in an Activity, never in Workflow code
•
iterating an unordered map or set yields a different order per run; sort the keys before looping
•
Workflow code runs on the SDK's single-threaded scheduler, and blocking it stalls or breaks replay
•
reading mutable process state makes the outcome depend on which Worker happens to replay the run
•
a logger that stamps time, an ORM, or an HTTP client called from Workflow code breaks replay silently
•
a Side Effect runs the impure code once and stores the result in history for every later replay
•
the error points at the divergent history event, not at the offending source line
E. Event history and replay
•
Workflow state is derived by replaying the event log; there is no state snapshot anywhere
•
the Worker returns Commands; the Service durably records the resulting Events
•
a Workflow Task delivers new events, runs the code to the next blocking point, and returns the commands produced
•
a completed Activity's result comes from history; replay never calls the Activity again
•
a Worker without the cached instance rebuilds it by re-executing from the first event
•
history has a warning threshold and a hard cap; crossing the cap terminates the Execution
•
a reset starts a new run that replays up to a chosen event and continues from there
•
the only place non-deterministic and external work is allowed to happen
•
a timeout, a lost response or a Worker crash re-runs it, so the code must be idempotent
•
pass a stable identifier down from the Workflow so a retry deduplicates at the downstream system
•
a long Activity must heartbeat or the heartbeat timeout declares it dead
•
the last heartbeat payload is handed to the next attempt so it resumes instead of restarting
•
an Activity that never heartbeats never learns that it was cancelled
•
no Activity Task round trip, but a short budget and no independent timeouts or visibility
G. Timeouts — and which one to actually set
•
the limit on a single Activity attempt; this is the one you almost always set
•
the limit on queue time before a Worker picks the Task up: a capacity signal, not a work signal
•
the limit on the whole Activity including queue time and every retry
•
the maximum gap between heartbeats, and the fastest way to detect a wedged Worker
•
an Activity needs Start-To-Close or Schedule-To-Close; with neither it could hang forever
•
retrying a queueing problem back onto the same queue does not fix it
•
a close timeout shorter than the retry budget silently cuts the retries short
H. Retries and retry policies
•
the default policy is unlimited attempts with exponential backoff
•
initial interval, backoff coefficient and maximum interval together shape the curve
•
0 means unlimited and 1 means no retry at all
•
listing an error type makes that failure terminal on the first attempt
•
a failed Workflow stays failed unless you attach one
•
the Activity can read its own attempt count and change strategy or give up
I. Failures, errors and cancellation
•
a returned error fails the Activity or Workflow; an unexpected exception fails only the Task
•
the Task retries indefinitely and the Execution stays open, stuck rather than dead
•
because Workflow Tasks retry forever, shipping corrected code lets a stuck Execution resume
•
unwrap the chain to reach the original error type and message
•
cancellation is delivered to the code and can run cleanup; termination stops the Execution immediately
•
a scope cancels its children, so compensation must run in a scope that survives cancellation
J. Messages: Signals, Queries and Updates
•
it is appended to history and the caller returns without a result
•
deliver a Signal and start the Execution if it does not exist, in one atomic call
•
a Signal racing the Workflow's return may never be handled; drain before finishing
•
a Query must not mutate state or issue commands, and never appears in history
•
even a closed Execution's Query is answered by replaying on a Worker that has the Definition registered
•
an Update is recorded in history and returns a value to its caller
•
a validator can refuse the Update without anything being written
•
a handler that awaits can expose half-updated state to the next handler
K. Timers and durable sleep
•
the Worker holds nothing while a Workflow sleeps, so a month-long wait costs one event
•
a timer guarantees a lower bound on the delay, not real-time precision
•
the idiomatic "wait for approval, or time out" pattern
•
moving a deadline means cancelling the pending timer and creating a new one
•
waiting inside an Activity burns an executor slot for the whole wait, and its timeout still runs
•
Schedules add pause, backfill, trigger and update, which a cron Workflow cannot do
•
Skip, BufferOne, BufferAll, CancelOther, TerminateOther and AllowAll decide what happens when the previous run is still going
•
after a long outage, actions missed beyond the window are skipped instead of stampeding
•
a schedule starts independent Executions; it never resumes the previous one
•
a schedule can stop itself after a failed action rather than repeating the failure on a timer
M. Composition: child Workflows, continue-as-new and Nexus
•
a child gets its own history, identity and timeouts; an Activity is one step inside the parent's history
•
Terminate, Request Cancel or Abandon decides what happens to a child when the parent closes
•
derive the child's Workflow ID from the parent's so two parents cannot collide on it
•
same Workflow ID, new Run ID, empty history, carried-over input
•
pending Activities and buffered Signals must be handled before calling it
•
before the history warning threshold, which is what makes an unbounded entity Workflow viable
•
a typed, durable call into another team's Namespace without sharing a task queue
N. Sagas, compensation and consistency
•
a saga replaces atomicity with explicit compensating actions
•
register each step's undo as that step succeeds, then unwind in reverse order
•
they retry, so they need their own idempotency and their own timeouts
•
the unwind path has to run for cancellation, not only for failure
•
a step that cannot be undone is offset by a new business action, such as a refund or a notification
O. Task queues, Workers and tuning
•
Workers long-poll the queue; the Service never pushes, so a Worker needs no inbound port
•
routing Activities to their own queue isolates their scaling from Workflow Tasks
•
a per-host queue pins follow-up work to the machine holding the local file or session
•
after the first Workflow Task the Service targets the Worker that already has the instance cached
•
when the Workflow cache is full an instance is evicted and rebuilt from event one
•
how many Tasks you fetch is tuned apart from how many you execute concurrently
•
rising queue time is a capacity problem, never a slow-code problem
•
draining in-flight Tasks on deploy, instead of orphaning them until their timeouts fire
P. Versioning and safe deployment
•
deploying a changed Definition replays old histories against it, and that is what breaks
•
a patch call records a marker so pre-existing runs keep the old branch while new runs take the new one
•
the multi-deploy sequence that retires a patch once no live run needs the old branch
•
renaming a local or changing a log line is safe; adding, removing, reordering or re-signing a command is not
•
Build-ID-based versioning routes new Executions to a new version while existing ones stay pinned
•
running the new Definition against real downloaded histories is what actually verifies compatibility
Q. Visibility and search attributes
•
you query indexed attributes with a limited dialect, not Workflow inputs or payloads
•
a just-started Execution may not appear in a list for a moment
•
Workflow type, execution status, task queue and the timestamps are indexed for you
•
a custom attribute must exist on the Namespace with a declared type before code can set it
•
a Workflow can update its own attributes as it progresses, and that write is a history event
•
a memo travels with the Execution and cannot be searched or filtered on
•
the test server jumps the clock, so a thirty-day timer completes in milliseconds
•
the clock advances when nothing is runnable, so a busy Workflow does not fast-forward
•
replacing Activity implementations tests branching, retries and compensation on their own
•
download a real history and replay the new code to catch a versioning break before deploying
•
an ephemeral local Service exercises the real client, Worker and task-queue path
•
it fails the Workflow Task, which retries forever, instead of failing the test
S. Data conversion, payloads and encryption
•
inputs, results, Signal arguments and error messages all live in history and are visible in the UI
•
payloads are capped, so large blobs must not travel through Temporal at all
•
store the object in your own bucket and pass only the key through the Workflow
•
a codec transforms the serialized bytes, so encryption stays transparent to Workflow code
•
decoding encrypted payloads for humans needs an endpoint you host; the Service never holds your key
•
error messages and stack traces also leave your process, and are encrypted separately from payloads
T. Observability and debugging
•
a spike means a bug or a nondeterminism error, not a business failure
•
the history shows every decision, wait and retry, and exactly where an Execution is blocked
•
an open Execution exposes the failing attempt, its error and the next retry time
•
cross-cutting hooks on client, Workflow and Activity calls, instead of edits in every Workflow
•
trace and tenant headers must be propagated deliberately; nothing is ambient across a Task boundary
•
the SDK logger suppresses duplicate lines during replay; a raw print statement re-emits them
U. Running Temporal: self-hosted and Cloud
•
persistence, the visibility index, scaling and version upgrades all become your responsibility
•
the history shard count cannot be changed later, and it bounds throughput
•
closed histories can be moved to cheap storage instead of simply being deleted
•
per-Namespace request and action limits shape client and Worker behavior before your own code does
•
mTLS certificates or API keys authenticate a client to one specific Namespace
•
cross-region replication is asynchronous, so a failover carries a non-zero recovery point
Keentune is not affiliated with or endorsed by the organizations whose documentation informs these maps.
Start practising Temporal
All about Temporal practice
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.
© 2026 SportaApp LLC