Recently, I spent a couple of weeks learning Temporal and building workflows. Each concept mapped to a problem I had met before: retry state after a crash, duplicate delivery at an external boundary, or a process stuck between two systems. I had spent years learning to solve those problems one service at a time. Temporal put them under one execution model.
I began with some skepticism. Temporal’s engineering lineage changed my view. Co-founders Maxim Fateev and Samar Abbas worked on Amazon Simple Workflow Service, then co-created Cadence at Uber after Abbas built the Durable Task Framework at Microsoft. Uber ran more than 100 Cadence use cases within three years. In an interview with Fateev, he says VCs approached them before they discussed starting a company. Temporal’s fifth Replay conference ran for three days at Moscone Center in 2026. CTOs and tech leads can evaluate it as infrastructure with a long production history and an established operator community.
Imagine an order flow with three calls: reserve stock, charge the card, create a shipment. Production adds the hard part. The process can die after the payment provider accepts the charge but before your service records the result. A queue can deliver the same message twice. Shipping can stay down for six hours.
One team adds an order_status column and a retry job. Another uses Kafka and a transactional outbox. A third writes a state machine around a queue consumer. Someone may reach for two-phase commit where the participants support it. Each design can work, but each team has to settle the same questions about retries, timeouts, duplicate delivery, compensation, and stuck executions.
The differences show up during an incident. One service has a useful audit trail. Another has logs spread across three systems. A third can tell you that an order is processing, but no one knows which action completed before the worker died.
Across several languages and frameworks, this turns into platform work even if no one calls it that.
The code is the small part
Temporal gives the process three building blocks:
- A Workflow describes the sequence and decisions.
- An Activity performs I/O, such as a database write or API call.
- The Temporal Service stores execution history and dispatches tasks to Workers.
A small order Workflow can look like this:
func OrderWorkflow(ctx workflow.Context, orderID string) error {
ctx = workflow.WithActivityOptions(ctx, workflow.ActivityOptions{
StartToCloseTimeout: 30 * time.Second,
})
for _, step := range []any{ReserveStock, ChargeCard, CreateShipment} {
if err := workflow.ExecuteActivity(ctx, step, orderID).Get(ctx, nil); err != nil {
return err
}
}
return nil
}The Activities contain the network and database code. Temporal enforces the timeout and retries each Activity under its retry policy. The Workflow keeps the business sequence readable.
This example leaves out compensation, signals, and custom retry rules on purpose. They belong in real designs, but they do not explain the core model.
Durability comes from history
Workers run your code. The Temporal Service records the commands that Workflow code produces and the results that Activities return. If a Worker crashes, another Worker replays the Workflow from its event history. The SDK supplies the recorded result of ReserveStock, then continues at ChargeCard.
sequenceDiagram
participant W as Worker
participant T as Temporal Service
W->>T: Write 1: schedule
T-->>W: Write 2: start
W->>W: Activity returns r-17
W->>T: Write 3: result r-17
Note over W,T: Worker process crashes
T-->>W: Dispatch replacement task
W->>T: Replay history
T-->>W: Restore result r-17
W->>T: Schedule ChargeCard
The real history contains more events than the diagram: Workflow tasks, Activity scheduling, attempts, timers, completions, and failures. Those writes let a Worker recover without guessing which step ran.
Replay imposes one important rule. Workflow code must produce the same commands from the same history. Network calls and other side effects belong in Activities. Teams also need replay tests and a versioning strategy when they change long-running Workflow code.
Temporal does not make an Activity side effect execute once. A payment Activity can charge the card and crash before Temporal records its result. The retry may call the payment provider again, so the Activity still needs an idempotency key. Temporal makes the retry durable and keeps it attached to the right execution; the payment system still has to deduplicate the charge.
One operational model across teams
The event history gives operators a common place to inspect an execution. Temporal Web shows its status, Activity attempts, failures, and pending work. Search Attributes let a team find executions by business fields such as OrderId or CustomerId, subject to the data policy for that field.
The SDKs add Workflow, Run, Activity, and attempt identifiers to logging context. Their Workflow loggers suppress duplicate messages during replay. Temporal also emits service and Worker metrics and supports OpenTelemetry tracing. A company still needs a metrics and trace backend, but teams can share correlation fields, dashboards, and alerts instead of inventing them per service.
That distinction matters. Temporal includes execution visibility and a Web UI. Prometheus, Grafana, Datadog, or another observability stack still needs configuration. The platform gives those tools a consistent execution model.
Operators can now ask the same questions across services:
- Which executions have failed or stopped making progress?
- Which Activity keeps retrying, and on which attempt?
- Are tasks waiting because a dependency is slow or because no Worker has capacity?
- Which business process produced this trace or log entry?
An event history also needs a retention and payload policy. Teams should not treat it as a compliance ledger by accident. Encryption, archival, and data removal requirements still need an owner.
Adoption becomes a platform decision
Temporal supports several language SDKs, while each team keeps its business code in its own Worker. Task Queues route work to the right Worker fleet. Namespaces provide boundaries for access, configuration, and resource isolation.
A platform team can turn those pieces into a paved road: namespace ownership, Worker templates, standard Search Attributes, idempotency conventions, dashboards, replay tests, and deployment rules. Product teams then learn one set of concepts for retries, timers, human input, and compensation.
Long-running timers and message passing deserve attention during an evaluation. A Workflow can wait for hours or months without holding a Worker process. Signals and Updates can carry an approval or an external event into a running Workflow, while Queries expose current state. These features replace many combinations of cron jobs, callback tables, and queue consumers.
The common model has limits. Teams still decide which failures deserve retries and which completed actions need compensation. They still own Activity idempotency. The platform team has to run the cluster or buy the cloud service, define tenancy boundaries, and support Workflow versioning across deployments.
A single database transaction or an idempotent queue handler may cover a small process. Temporal earns its place when several steps cross system boundaries, wait for external input, or require an operator to inspect and repair one execution. The enterprise case gets stronger when several teams have built different versions of that machinery.
I would start with one process that already has retries, status tables, and a repair runbook. The pilot should test the operating model as much as the SDK: who owns the namespace, how on-call engineers find a stuck order, how Workers deploy, and how the team changes Workflow code with open executions. That will show whether Temporal can serve as a shared execution layer rather than one more tool owned by one team.