Illustrated technology atlas · Temporal durable execution

Temporal illustrated atlas

Best practices

For technically literate software engineers. Fundamentals, architecture, production practices and published case studies; TypeScript teaching excerpts and proposed insurance examples. Current living docs checked 9 October 2026, without claiming a single latest SDK/Server version. Exact examples are reviewed, not executed. Case studies are vendor-published accounts, not independently measured results. Advanced Nexus, standalone Activities, exhaustive Server operations and pricing are outside scope.

Research date: 2026-10-09

Part 1 · Fundamentals

Durable execution: the core mental model

Prerequisites: Start here / basic technical literacy

Clients and application Workers communicate with the Service. The Workflow-to-Activity arrow means scheduling through the Service, not an in-process HTTP call. [S03] [S04]

Objective and vocabulary verified

Understand the three responsibilities. A Workflow Definition is code; an Execution is one durable invocation. An Activity performs external work. A Worker is your application process running SDK code. The Temporal Service records progress and coordinates Tasks; your Workers execute your business code.

[S01] [S04] [S03]

What durability buys verified

A durable timer or a wait for input survives a Worker restart. Waiting does not require one thread or pod per customer. Progress still requires a healthy Service, available Workers, compatible code and recoverable dependencies. Durable does not mean every failure disappears.

[S09] [S27]

Worked example and decision synthesis

Proposed example: a policy renewal validates documents, waits for review, collects payment, and issues a policy. This is a strong fit when lost progress and manual recovery are costly. A tiny local operation may be better kept in one database transaction; adding durable orchestration carries deployment and maintenance costs.

[S01] [S31]

Pitfall → next improvement synthesis

Do not treat Temporal as the only copy of policy, payment or audit data. Define who owns domain records, what the Workflow stores, and which side effects require deduplication. Begin with a stable operation identity and a small, explicit input object.

[S02] [S04]

Keep this: Let the Workflow own the process; let Activities own external effects.

Check yourself: Does a Workflow waiting for a reviewer need a dedicated pod?

No. Its durable state can be reconstructed from History. Workers process Tasks when progress is possible; cached state is an optimization.

Part 2 · Fundamentals

Architecture: application plane and Service plane

Prerequisites: 01-mental-model

Simplified responsibilities and RPC paths. Storage technologies are intentionally unspecified. Visibility indexing is asynchronous; omitted internal queues and replication paths are not absent from the real system. [S03] [S26] [S29]

Objective and responsibilities verified

Read the Service boundary. Frontend accepts and routes RPCs. History maintains execution state, timers and Event History. Matching coordinates Task Queues and dispatch. The Server’s internal Worker service performs system background work; it is distinct from your application Worker fleet. Persistence is required.

[S03] [S26]

Task path verified

Simplified regular Activity path: a Client starts an Execution; a Worker polls a Workflow Task and returns Commands; the Service records state and schedules an Activity Task; an Activity Worker executes it and reports completion; a later Workflow Task resumes decision-making. Workflow and Activity Tasks have distinct queues even when their configured name is shared.

[S28] [S05]

Decision: Cloud or self-hosted synthesis

Cloud lets the vendor operate the Service, while you operate your application Workers and dependencies. Self-hosting adds storage, server upgrades, security and service health to your responsibilities. Choose using operational capacity, data requirements and recovery objectives; a local development server is a learning tool, not evidence of production readiness.

[S31] [S30]

Pitfall → next improvement synthesis

Scaling Worker pods does not automatically scale a self-hosted persistence database. Map the failure domains separately: client ingress, Worker fleet, Temporal Service, domain database and provider APIs. Exercise loss of each boundary before moving a critical process.

[S26] [S31]

Keep this: History provides durability; Matching dispatches; your Workers execute.

Check yourself: Does Temporal Cloud execute your Activity business logic inside its Service?

The regular model keeps business logic in your application Workers. Cloud operates the Temporal Service; Worker hosting is a separate deployment responsibility.

Part 3 · Fundamentals

History, replay and deterministic decisions

Prerequisites: 01-mental-model, 02-service-architecture

A replacement Worker reads History, receives recorded Activity results, and reaches the pending-work frontier. Cache optimizations can avoid replaying everything for every Task. [S01] [S27]

An inserted Activity disagrees with a historical Timer Command. This is illustrative; actual compatibility depends on SDK and change semantics. [S02] [S17]

Objective and mechanism verified

A Workflow issues Commands through SDK APIs. The Service records resulting events. Replay runs compatible Workflow code against recorded History, reconstructing the state needed to continue. A completed Activity’s recorded result is supplied during replay; that completed Activity is not rerun simply because a Workflow Worker restarted. Sticky caching can reduce replay work.

[S01] [S27]

Determinism is a compatibility contract verified

Keep HTTP, database access, filesystem operations and LLM calls in Activities. Workflow code must make compatible Command decisions for the same recorded History. Use the SDK’s supported deterministic APIs for time and randomness rather than importing arbitrary runtime behavior. Deterministic does not mean every Activity or business result is predictable.

[S02]

Worked failure and decision synthesis

Suppose History records validate → timer → issue. A release that inserts a new Activity before the old timer can disagree with that History. Retrying the same incompatible code is not a fix. Decide whether to keep executions on their original deployment or introduce a compatible patch path.

[S17] [S16]

Pitfall → next improvement synthesis

Replay is not a database rollback or arbitrary heap snapshot. Build a representative History corpus with executions at different waits and failure states; use it to assess code compatibility. Store documents outside History and retain stable references for later Activity use.

[S15] [S32]

Keep this: Recovery replays compatible decisions and recorded results.

Check yourself: Why can an LLM call be safe inside an Activity but unsafe inside a Workflow?

The model invocation is external and nondeterministic. Its completed result can be recorded and reused during replay; calling it directly while replaying could change the decision sequence.

Part 4 · Fundamentals

Retries, timeouts, heartbeats and idempotency

Prerequisites: 03-history-replay

Queue delay, per-attempt execution, heartbeat gap and total Activity budget are separate scopes. The timeline is illustrative, not a benchmark. [S07]

A crash after provider commit can cause another Activity attempt. A stable business key permits the provider to return the prior result rather than applying the effect again. [S04] [S05]

Three kinds of retry verified

Activity Executions retry transient failures by default. Workflow Task retries recover decision-task failures; they are different from restarting the whole business process. A Workflow Execution has no Retry Policy by default. Classify permanent business rejection separately from infrastructure failure instead of retrying every exception indefinitely.

[S06]

Timeout and heartbeat boundaries verified

Start-To-Close bounds one Activity attempt. Schedule-To-Close bounds its full execution, including retries. Schedule-To-Start bounds queue delay and is non-retryable; monitoring queue delay is usually preferable. Heartbeats detect stalled long Activities, convey checkpoints and enable cancellation delivery. A timeout does not forcibly kill remote work; use cooperative cancellation and external fencing where required.

[S07] [S05]

Worked ambiguous-success scenario synthesis

A payment commits, but the Worker crashes before reporting completion. The Service can retry the Activity. Proposed solution: reuse an operation key such as payment:order-42 and require provider-side deduplication, or implement a transactional local idempotency record. A new attempt number creates a new payment, defeating the purpose. Local deduplication alone cannot make an unrelated external provider atomic.

[S04] [S05]

Decision → pitfall → improvement synthesis

Set retry budgets from business urgency and dependency recovery behavior. Give a long document extraction a heartbeat checkpoint; fail malformed configuration quickly. Split operations with different failure profiles. For a provider without safe deduplication, reconcile ambiguous outcomes before retrying an irreversible action.

[S07] [S06] [S14]

Keep this: Temporal remembers completion; you must make repeated external attempts safe.

Check yourself: Does replay safety guarantee that a card is charged only once?

No. Completed results are replayed safely, but an unacknowledged Activity attempt may have changed the provider. Exactly-once business effect requires an appropriate idempotency or reconciliation design.

Part 5 · Applications

Human approval: Signals, Updates, Queries and timers

Prerequisites: 04-retries-idempotency

Proposed insurance example. The authenticated API owns authorization; the Workflow owns waiting and routing. The sample code uses expiry while the diagram also shows escalation as a design choice. [S08] [S09] [S24]

Compare server acceptance, mutation completion and read-only state. An Update’s completion is the handler’s completion, not necessarily the whole Workflow’s completion. [S34]

Objective and interaction choice verified

A Signal adds durable input and returns when the Service accepts it, before the handler necessarily applies it. An Update can validate, change state and return a handler result. A Query reads Workflow state without adding a History event and requires an available Worker. Choose based on the acknowledgement the caller needs.

[S34]

Proposed insurance flow synthesis

An authenticated API checks tenant, actor and policy eligibility before sending a reviewer decision. The Workflow waits for the decision or a deadline, then issues, rejects or escalates. Treat late decisions, duplicates and an approval arriving near the deadline as explicit business policies. Durable timers resume once Service and Workers can progress; they are not a guarantee of exact wall-clock action during outages.

[S09] [S24]

TypeScript: first decision wins synthesis

// Teaching excerpt: Activity interface + implementations are omitted.
import { condition, defineSignal, proxyActivities,
  setHandler } from '@temporalio/workflow';
type Decision = { id: string; approve: boolean };
type Acts = { issuePolicy(id: string, key: string): Promise<string> };
const { issuePolicy } = proxyActivities<Acts>({
  startToCloseTimeout: '30 seconds',
  scheduleToCloseTimeout: '5 minutes',
});
export const decisionSignal = defineSignal<[Decision]>('decision');
export async function reviewPolicy(policyId: string) {
  const state: { decision?: Decision } = {};
  setHandler(decisionSignal, (d) => {
    if (!state.decision) state.decision = d;
  });
  const arrived = await condition(
    () => state.decision !== undefined, '48 hours');
  const chosen = state.decision;
  if (!arrived || !chosen) return { status: 'expired' };
  if (!chosen.approve) return { status: 'rejected' };
  return { status: 'issued', policy: await issuePolicy(
    policyId, `issue:${policyId}`) };
}

[S35]

Decision, pitfall and improvement synthesis

This excerpt accepts the first decision and expires after 48 hours; it omits transport authorization, validation and Activity implementations. Reviewed against the documented API, not executed. Use Updates if the API needs an applied-result acknowledgement. For async handlers, coordinate interleaving at await points and finish handlers before completion or Continue-As-New.

[S08] [S19]

Keep this: Waiting is durable; acceptance is different from completion.

Check yourself: Which primitive fits an API that must return whether approval was applied?

An Update can return the handler result after validation and mutation. A Signal acknowledgement only establishes server acceptance. The API still needs business authorization.

Part 6 · Applications

Sagas: recover the business, not yesterday’s database

Prerequisites: 04-retries-idempotency

Proposed checkout Saga. Compensations are registered for potential side effects, including a booking that may have happened despite a failed acknowledgement. [S10] [S11]

A failed remedy can require retries or operator reconciliation. Temporal coordinates the work; it does not make an impossible business reversal possible. [S10]

Objective and mechanism verified

A Saga coordinates local operations and compensates when a later step cannot complete. Compensation often runs in reverse order. It permits intermediate states and does not give cross-service ACID isolation. Register safe compensation before an effect that might occur before success is acknowledged; the compensator must tolerate both absence and repetition.

[S10] [S11]

Proposed checkout case synthesis

Reserve inventory, charge payment, then book shipping. If booking fails, cancel any booking that exists, refund any committed charge, and release the reservation. This design assumes these remedies exist and that eventual reconciliation is acceptable. An email cannot be unsent; a shipped order may require a return rather than a technical undo.

[S10] [S11]

Decision and residual cost synthesis

Prefer forward retry for a recoverable outage; compensate when the business abandons the operation. A compensation that also fails needs a generous retry policy and an explicit unresolved state. Cancellation cleanup needs a non-cancelled scope/context; termination cannot be relied on to run Workflow cleanup. External systems may need fencing to prevent stale forward attempts racing a compensation.

[S37] [S39] [S40]

Pitfall → next improvement synthesis

Do not let a catch block mark an order refunded before money is reconciled. Proposed improvement: persist the pending remedy and correlation key, alert on its age, and provide an operator route. Test ambiguous completion and simultaneous cancellation, not only a clean exception before an effect.

[S10] [S15]

Keep this: Compensation is a new business operation with its own failure modes.

Check yourself: Is a refund the same thing as rolling back the payment database?

No. A refund is a new business transaction. Other observers may have seen the charge, and refund execution can fail independently.

Part 7 · Applications

Case studies: Box, Replit and Strada

Prerequisites: 05-human-workflows, 06-sagas

Reported queue/state complexity, durable operations and controlled validation; simplified teaching sketch. [S12]

Reported Workflow ownership and Activity boundaries; simplified teaching sketch. External resource ownership still requires a safe protocol. [S13]

Reported four phases, independent children, shared-context serialization and persistence before sending; simplified teaching sketch. [S14]

Box • reported, 15 April 2024 verified

Box describes complex content-tree operations implemented with custom queues, pagination and state machines. It adopted durable Workflows and validated both traversal coverage and reimplemented business logic, using simulation followed by tenant-by-tenant rollout. Transferable lesson: migration correctness includes what was touched and what each operation did.

[S12]

Replit • reported, 15 September 2025 verified

Replit describes a Workflow per agent lifecycle, with Activities for failure-prone operations and Updates for human interaction. The control plane coordinates agent and container lifecycles. Transferable lesson: a stable lifecycle owner helps recovery; it does not by itself fence stale external processes or make tools idempotent.

[S13]

Strada • reported, 27 August 2026 verified

Strada describes insurance email phases of intake, extraction, reasoning and delivery. Attachment and reasoning Child Workflows isolate failures. Shared-context reasoning is serialized by a long-lived orchestrator; decisions are persisted before sending. Transferable lesson: durable waiting and ordered shared-context work address different problems.

[S14]

Decision and evidence limits synthesis

These are customer accounts published by Temporal. The figures redraw the reported patterns, not verified internal deployments. They establish useful use cases, not a comparative benchmark. For your pilot, measure recovery time, duplicate effects and engineering effort. Historical note: the Coinbase case study on the vendor site explicitly describes Cadence, a predecessor; it should not be silently counted as evidence of a modern Temporal deployment.

[S12] [S13] [S14] [S33]

Pitfall → next improvement synthesis

Avoid importing a customer’s scaling or reliability outcome into a different workload. Proposed improvement: borrow one mechanism, state its assumptions, and test it against your own incident scenarios and dependency budgets. Start with a process whose repair cost is already visible.

[S12] [S13]

Keep this: The shared pattern is durable process ownership with isolated failure boundaries.

Check yourself: Which Strada pattern addresses two agents reasoning over the same customer state?

The serial orchestrator orders shared-context requests. Replay durability preserves pending work, but serialization is the separate mechanism preventing conflicting reasoning.

Part 8 · Best practices

Testing: business outcomes and historical compatibility

Prerequisites: 03-history-replay, 04-retries-idempotency

Activity, Workflow integration and replay tests answer different questions. Failure injection checks recovery across a real acknowledgement boundary. [S15] [S05]

Objective and test layers verified

Test Activity logic and external contracts in isolation. Use Workflow integration tests with mock Activities and time skipping for deadlines. Replay representative histories against candidate code to detect incompatibility; include open and closed executions from affected Workflow Types and Task Queues. Fail the deployment check when relevant replay fails.

[S15] [S36]

Worked crash experiment synthesis

Proposed exercise: make a fake payment provider commit, then stop the Worker before completion acknowledgement. Restart it and check that the provider records one business payment and the Workflow eventually progresses. Also test duplicate reviewer input, permanent rejection and a stalled extraction with heartbeat recovery. These target the failure boundary rather than mirroring the code.

[S36] [S05] [S07]

Decision and coverage limits synthesis

Use integration tests for durable waits, mocks for deterministic failure injection, and a smaller end-to-end suite for real dependency behavior. History replay checks compatibility with sampled histories; it does not execute external Activities or prove every possible branch, idempotency protocol or business invariant.

[S15] [S02]

Pitfall → next improvement synthesis

A fresh happy-path test can pass while yesterday’s approvals fail to replay. Preserve sanitized, representative histories by workflow version and state. Refresh that corpus as production paths evolve; add a separate dependency contract test for idempotency and cancellation behavior. Examples in this atlas are teaching excerpts, not a verified runnable project.

[S15] [S05]

Keep this: Test current behavior and replay old histories; neither substitutes for the other.

Check yourself: What does a passing History replay test fail to prove?

It does not prove an external effect is idempotent, that every history is covered, or that current business logic is correct. It only establishes compatibility for the tested histories.

Part 9 · Best practices

Safe upgrades for processes that outlive a release

Prerequisites: 08-testing

Conceptual comparison of version behaviors, not a CLI recipe. Current defaults, support levels and transition semantics must be checked against the deployed SDK and Server. [S16] [S17]

Objective and current concepts verified

Current Worker Versioning uses Worker Deployments and Deployment Versions. Pinned Workflows stay on one version; Auto-Upgrade Workflows can move with the current version and must remain replay-safe. Patching preserves different decision paths where required. Pre-2025 experimental Worker Versioning guidance is legacy; use current docs and verify SDK/Server support.

[S16] [S17]

Proposed approval rollout synthesis

For an approval that may wait weeks, choose pinned execution if keeping old code capacity is affordable. Start new work on v2 while existing v1 executions finish. With Auto-Upgrade, keep compatible branches for recorded decisions and test histories from every relevant waiting state. Routing a run to new code is not proof that its History matches.

[S16] [S17] [S15]

Pitfall → next improvement synthesis

Deleting old Worker capacity too early can strand pinned runs. A normal Kubernetes rolling deployment does not replace a Temporal version strategy. Keep Activity contracts and external schemas backward-compatible too. Proposed improvement: record deployment identity in incident context, replay before rollout, and verify old execution reachability before retiring capacity.

[S16] [S17]

Keep this: A long-lived Workflow carries a compatibility obligation across deploys.

Check yourself: Can Auto-Upgrade remove the need to patch an incompatible Command change?

No. Auto-Upgrade routes work to current code; that code must still interpret existing History compatibly.

Part 10 · Best practices

Capacity, fan-out, payloads and History growth

Prerequisites: 09-safe-upgrades

Proposed tuning loop separates Task dispatch, Worker execution and downstream constraints; no quantitative throughput claim is implied. [S18] [S28]

Continue-As-New retains Workflow identity and starts a fresh Run. Domain documents stay outside inline History; carried state must be explicit. [S19] [S20] [S32]

Objective and capacity model verified

A slot is capacity to execute a Task; a poller retrieves Tasks. Worker tuners manage slot suppliers, including fixed and resource-based strategies. Current docs warn against combining tuners with legacy maxConcurrent task settings. Increasing concurrency without dependency headroom can amplify DB contention, provider throttling and retries.

[S18]

Worked capacity decision synthesis

Proposed example: invoice extraction uses a provider quota and a finite DB pool. Isolate its Activity queue from lightweight approval work, bound parallelism, and monitor queue delay plus provider errors. Choose more Workers only when capacity is actually the bottleneck. CPU-bound Activities may need separate processes or fleets rather than ever-higher concurrency.

[S18] [S28]

History and payload budget verified

Continue-As-New closes a run and starts a fresh History with the same Workflow ID and a new Run ID, taking explicitly supplied state. Current Cloud docs list a 2 MB single-request payload cap, a 4 MB History transaction cap, and History limits of 51,200 events or 50 MB, with warnings at 10,240 events or 10 MB. Treat these as ceilings, not design targets.

[S19] [S20]

Pitfall → next improvement synthesis

One immortal entity Workflow can accumulate unbounded messages, state and History. Finish handlers before Continue-As-New and carry the remaining queue/cursor deliberately. Store large documents in external storage; carry immutable references and versions so later attempts read the intended object. Benchmark replay cost and reduce per-run fan-out before hitting limits.

[S19] [S32] [S20]

Keep this: Bound the work per run, and respect the slowest downstream budget.

Check yourself: Does Continue-As-New automatically transfer every local variable to the next Run?

No. The next Run receives the inputs you supply. Carry the minimal necessary state and account for active handlers and pending work.

Part 11 · Best practices

Operate and secure the whole process

Prerequisites: 10-capacity-history

Proposed operations model joins Service health, Worker progress and business outcomes. Visibility does not promise instantaneous list results. [S21] [S29]

Payload codecs protect encoded payload bytes, while indexed metadata must remain readable by the Service. Application access control is a separate boundary. [S22] [S23] [S24]

Objective and observability verified

SDK metrics, logs and traces complement Event History. Track queue delay, Worker slots, retry load and replay errors, then add business signals such as age in stage, pending approvals and unresolved refunds. Use Workflow ID and Run ID for correlation in logs/traces; avoid per-execution metric labels. Use the Workflow context logger to avoid ordinary I/O and duplicated replay logs.

[S21] [S18]

Read the correct state surface synthesis

Visibility is an asynchronous search index for List and Count and may briefly lag. A Query reads local business state via a Worker; DescribeWorkflowExecution looks up execution information by ID. Neither a search filter nor a Workflow status replaces business authorization. Proposed runbook: inspect queue delay, Worker availability, recent version changes and the failing Activity’s external dependency before issuing resets or termination.

[S29] [S34]

Data and access boundaries verified

Cloud supports API key or mTLS namespace authentication. Separate environment credentials and Namespace access. A client-side Payload Codec encrypts encoded payloads before they reach the Service. Search Attribute names and values remain readable for indexing and are not protected by that codec. Failure text requires explicit encoding configuration; sensitive logs need their own controls.

[S30] [S24] [S22] [S23]

Proposed insurance decision → improvement synthesis

Keep customer documents in controlled storage, use opaque non-PII operation identifiers, and authorize reviewer actions at your API. If decryption in the UI is needed, secure the codec server and manage keys for the lifetime of retained executions. Set retention to operational requirements and test credential rotation. Do not equate transport TLS with payload privacy or tenant authorization.

[S22] [S24] [S23]

Keep this: Observe business progress, and protect payloads and access separately.

Check yourself: Can you safely put a customer email into a Search Attribute because payload encryption is enabled?

No. Search Attributes are not processed by the Payload Codec. Keep sensitive data and PII out of their names and values.

Part 12 · Further improvements

Adoption: complement events, migrate deliberately, measure results

Prerequisites: 07-published-cases, 11-operate-securely

Proposed architecture. Outbox, relay, consumer and Workflow handoffs must tolerate repeats; the sources establish component roles, not this exact product topology. [S25] [S01] [S28]

Proposed pilot compares recovery and business correctness with operating cost. Improvement is a hypothesis until measured. [S12] [S15] [S31]

Objective and placement synthesis

Kafka captures, retains and distributes event streams. Temporal tracks an individual process’s decisions, waits and recovery. Their responsibilities can complement each other. Proposed placement: use events for facts consumed by many services, and Workflows for an operation requiring coordinated progress. A simple local transaction or disposable background task may not justify the extra platform.

[S25] [S01]

Worked bridge design synthesis

Proposed integration: the API commits domain state and an outbox record together; a relay publishes an event; a bridge consumer uses a stable operation identity to start or signal a Workflow. Each handoff has retry and deduplication behavior. This diagram is not a cross-system atomic transaction: account for publication duplicates, consumer retries and Workflow ID reuse/conflict policy.

[S25] [S28] [S01]

AI improvement path synthesis

Proposed agent design: put model calls and tools in Activities, persist approved decisions before delivery, bound iterations/cost, and serialize work when customer context overlaps. Model calls may differ across attempts; recorded completion supports replay but does not prove answer quality. Add evaluations and policy checks as separate controls. Strada’s reported architecture supplies a useful precedent rather than a universal recipe.

[S02] [S38]

Pilot and decision synthesis

Start with one approval or refund process. Establish baseline repair effort, completion age, duplicate effects and recovery time. Inject Worker failure, simulate a provider outage and deploy code while executions wait. Expected benefit: less lost progress and repair work. Residual costs: Worker operation, version compatibility, dependency contracts and platform fees or self-hosting effort. Decide from measurements, not a logo wall.

[S12] [S15] [S31]

Pitfall → further study synthesis

Do not move every service call into a Workflow because durable execution sounds attractive. Expand only after a useful pilot. Next study paths: Child Workflow boundaries, cancellation semantics, Schedules, current Worker Deployment rollout APIs, external payload storage and Temporal Nexus. This atlas intentionally does not provide exhaustive Server tuning, Nexus, standalone Activities, pricing or a runnable app.

[S31] [S32] [S16]

Keep this: Adopt durable orchestration for a costly process failure, then prove the benefit.

Check yourself: What evidence would justify expanding the pilot?

Measured recovery and repair improvements with safe duplicate handling, acceptable completion latency, compatible releases and an operational cost the team can sustain.

Sources & further reading

[S01] Workflow Execution
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Durable executions, replay, execution identity and cached state.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S02] Workflow Definition
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Deterministic Commands and external interactions in Activities.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S03] Temporal architecture
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Frontend, History, Matching, persistence and application responsibility.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S04] Activities
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Activities represent external operations and should be idempotent.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S05] Activity Execution
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Task loss detection, attempts, cancellation and recorded completion.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S06] Retry Policies
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Activity retries, Workflow Task retries and Workflow Execution retry defaults.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S07] Detecting Activity failures
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Timeout scopes, heartbeat and queue delay monitoring.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S08] TypeScript message passing
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Signals, Queries, Updates, handlers and condition.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S09] TypeScript Timers
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Durable timers and resource-light waiting.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S10] Saga Pattern
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Compensation order, pre-registration, idempotency and consistency limits.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S11] Compensating actions
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · 2023-05-02
Supports: Ambiguous completion and compensation semantics.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S12] Box: a central brain
Temporal Technologies · case-study · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · 2024-04-15
Supports: Folder traversal, custom queue/state migration, simulation and tenant rollout.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S13] Replit Agent
Temporal Technologies · case-study · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · 2025-09-15
Supports: Workflow per agent, Activities and human interaction.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S14] Strada insurance agents
Temporal Technologies · case-study · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · 2026-08-27
Supports: Email phases, independent children, serial context coordination and persist before delivery.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S15] TypeScript testing
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Integration tests, time skipping and history replay in CI.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S16] Worker Versioning
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Worker Deployments, Pinned and Auto-Upgrade behaviors.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S17] TypeScript versioning
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Patching and legacy Worker Versioning notice.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S18] Worker performance
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Slots, slot suppliers, pollers and tuner incompatibility with legacy concurrency settings.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S19] Continue-As-New
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: New Run ID and fresh History with same Workflow ID.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S20] Cloud system limits
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Payload and History limits; warning thresholds.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S21] TypeScript observability
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: SDK metrics, tracing, Workflow logs and cardinality.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S22] Codecs and Encryption
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Client-side payload encryption, codec servers and failure encoding.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S23] Search Attributes
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Indexed metadata is readable by the Server and not protected by payload codecs.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S24] Cloud security controls
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Namespace boundaries, credentials, retention and data protection.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S25] Kafka introduction
Apache Software Foundation · documentation · accessed 2026-10-09 · Kafka 4.2 conceptual introduction; not an installation recommendation · Update date not stated
Supports: Event streaming, durable records, producer and consumer roles.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S26] Temporal Server
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Four independently scalable Server service roles.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S27] Workflow overview
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Replay reconstructs state; no process memory snapshot is required.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S28] Task Queues
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Workers poll when capacity exists; Workflow and Activity queues.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S29] Visibility
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Asynchronous search index, eventually consistent List and Count.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S30] Cloud getting started
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: API key or mTLS namespace authentication.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S31] Self-hosted guide
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Local dev server and production operating responsibilities.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S32] TypeScript data handling
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Converter, codec and external storage responsibilities.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S33] Coinbase historical Cadence case
Temporal Technologies · case-study · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · 2024-08-29
Supports: The case explicitly concerns Cadence, a predecessor to Temporal.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S34] Message passing concepts
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Signals, Updates, Queries and caller acknowledgement needs.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S35] Workflow TypeScript API
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: proxyActivities, condition and handler definitions; cancellation scopes.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S36] Mock Activity Environment API
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Testing Activity context, heartbeat and cancellation in isolation.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S37] Distributed transaction patterns
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Saga and early-return tradeoffs.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S38] Durable AI
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Durable agent and pipeline use cases.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S39] Cancellation and Termination
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Cancellation versus termination and safe cleanup.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.
[S40] TypeScript cancellation scopes
Temporal Technologies · documentation · accessed 2026-10-09 · Living documentation, accessed 2026-10-09 · Update date not stated
Supports: Non-cancellable cleanup scope and cancellation propagation.
Read the linked primary source for the mechanism and scope summarized in the cited lesson.