What a Temporal implementation involves
Temporal is a durable execution platform. Developers write workflows as ordinary code with an SDK, and the Temporal Service records each step in an Event History. If a worker crashes or a downstream system is down for an hour, the workflow resumes where it stopped, with timers, retries and waiting state preserved. It suits payment and order flows, onboarding, provisioning and other processes that span several systems.
Workflow code orchestrates. Activities do the work that touches the outside world, such as API calls and database writes. Workers, which you run, poll task queues and execute both. The service can be self-hosted from the MIT-licensed Temporal Server or used as Temporal Cloud, the managed service from Temporal Technologies; workers stay in your environment either way.
The implementation work is in mapping processes into workflow designs, writing replay-safe code, handling failure and compensation, versioning code while executions are running, and operating workers and, when self-hosted, the service.
Map the process before writing code
Discovery for Temporal focuses on side effects, waiting and failure.
External calls
Every call to another system becomes an Activity with its own timeouts and retry policy. Agree which errors are retryable and which fail the step.
Waiting on people and events
Approvals, callbacks and customer actions arrive as Signals or Updates. Deadlines become durable timers that survive restarts.
Side effects that must not repeat
An Activity can run more than once after a timeout or crash. Payments, emails and ledger postings need idempotency keys the downstream system honors.
Compensation
When a later step fails after earlier ones succeeded, the workflow runs undo steps such as refunds and cancellations, defined per step during design.
Long-running entities
Event History has a hard limit of 51,200 events or 50 MB. Workflows that run for months or loop indefinitely use Continue-As-New to start a fresh history.
Determinism and versioning are the core skill
Temporal recovers a workflow by replaying its Event History through the workflow code. The code must issue the same commands in the same order on every replay, so it cannot read the system clock, generate random values or call the network directly. It uses the SDK's replay-safe APIs, and all I/O goes into Activities. A mismatch raises a non-determinism error and that execution stops progressing until the code is fixed.
Changing workflow code while executions are running needs a versioning plan. Temporal recommends Worker Versioning: workers belong to a Worker Deployment with a Build ID, pinned workflows finish on the version they started on, and auto-upgrade workflows move to new versions and rely on patching to stay replay-safe. An earlier experimental versioning method was scheduled for removal from Temporal Server in March 2026, so code that uses it needs a plan.
Replay tests catch these mistakes before deployment. We replay recorded histories against new code in CI and fail the build on any non-determinism error.
What the build covers
Temporal work is mostly software engineering, done with your developers in their repositories and languages.
Workflow code
- Workflow definitions with Signals, Queries and Updates.
- Compensation and cancellation handling.
- Continue-As-New for long-running entities.
Activities and integrations
- Activities for core systems, payment providers and messaging.
- Timeouts, retry policies and heartbeats for each call.
- Idempotency keys passed to downstream APIs.
Testing
- Unit tests with the SDK test environment.
- Replay tests against recorded histories in CI.
- Failure and load tests before rollout.
Workers
- Container images per task queue with resource limits.
- Concurrency and poller settings tuned under load.
- Build IDs wired into CI/CD for Worker Versioning.
Migration paths and rollout
Home-grown orchestration often spreads one process across message consumers, scheduled jobs and a status column. Model it as one workflow, move each consumer's work into Activities, and send new requests to the workflow while existing ones finish on the old path.
Temporal began as a fork of Uber's Cadence, so concepts map closely, but the SDKs and APIs are not compatible. Port code per workflow type and let existing Cadence executions finish.
Flows in AWS Step Functions, BPM engines or schedulers translate into code with the same steps, timeouts and retries. Map each old state to a workflow function or Activity and port error handling explicitly.
Start with one workflow type with clear failure cases, prove it in staging with replay and load tests, then move traffic in stages. Train developers on determinism and versioning before they own workflows.
Design the self-hosted service
Temporal Server runs four services on a persistence store and a visibility store. Running each separately lets them scale independently.
| Component | Role | Design notes |
|---|---|---|
| Frontend | Stateless gRPC gateway (port 7233) for rate limiting, authorization and routing. | Place behind a load balancer. Client mTLS and authorization apply here. |
| History | Persists workflow state and Event History, partitioned into History Shards. | The shard count is fixed once the database is initialized, so size it during design. |
| Matching | Hosts task queues and matches workers to tasks. | Scales horizontally with task queues and polling load. |
| Worker service | Internal background processing such as replication and system workflows. | Run more than one instance for availability. |
| Persistence | Cassandra, PostgreSQL or MySQL. SQLite is for development and testing only. | Use a highly available database at a version Temporal tests for your release. |
| Visibility | Lists and searches executions: Elasticsearch, OpenSearch, PostgreSQL 12+ or MySQL 8.0.17+. | Temporal recommends Elasticsearch for production. Cassandra cannot be used for visibility. |
Secure the service and its namespaces
A self-hosted Temporal Server allows every API request until authorization is configured, because the default no-op authorizer permits all calls. Production needs a ClaimMapper and an Authorizer. The built-in JWT ClaimMapper validates tokens against a JWKS endpoint and reads read, write, worker and admin permissions per namespace, so tokens can come from Keycloak, Microsoft Entra ID or another identity provider.
Enable mTLS for clients and workers on the frontend and for internode traffic, accept client certificates only from your internal CA, and turn on SSO for the Web UI through its OAuth settings.
Event Histories store workflow inputs and Activity results. For personal or financial data, add a Payload Codec that encrypts payloads in the worker, and treat any Codec Server that decrypts data for the UI as a privileged system. Use namespaces to separate teams and environments, with retention set per namespace.
Upgrades, backups and day-two operations
How do server upgrades work?
Upgrade one minor version at a time, first moving to the latest patch of your current minor version, and update the database schema with Temporal's schema tools before each server upgrade. Compatibility is only guaranteed between successive minor versions, and skipping versions can leave older data unreadable.
What do we back up?
The persistence database holds all workflow state, so its backups and point-in-time recovery are the recovery plan. Back up the visibility store too, keep server and namespace configuration in version control, and rehearse a restore.
What do we monitor?
Schedule-to-start latency, workflow task failures, persistence latency and worker resource use. Temporal publishes Grafana dashboards you can import as a starting point.
Temporal implementation questions
Should we self-host or use Temporal Cloud?
Temporal Cloud runs the service while your workers stay in your infrastructure. Self-hosting gives full control of data location and network paths, and your team runs the databases, services, upgrades and on-call. Workflow code is the same for both.
Can we use the official Helm chart in production?
The chart installs the server components and expects you to provide the databases. Persistence, visibility, certificates and authorization sit outside the chart and need their own design.
Which language should workflows use?
The one your team maintains. Official SDKs cover Go, Java, Python, TypeScript, .NET, Ruby, PHP and Rust, and different languages can share task queues.
Does Temporal help with audit evidence?
Event Histories record each step with timestamps, which supports evidence for SOC 2, ISO 27001 or DORA controls. DeployOpen can assess the deployment against those requirements; we do not issue audit reports or certifications.
Scope and handover
Effort depends on the number of workflow types, the systems Activities call, how much existing orchestration is replaced, self-hosting or Temporal Cloud, availability targets and the languages in use.
DeployOpen maps processes into workflow designs, builds workflows, Activities and tests with your developers, deploys and hardens the Temporal service or connects workers to Temporal Cloud, sets up mTLS, authorization, SSO and payload encryption, and runs the rollout. Handover includes code in your repositories, replay test suites, versioning guidelines, cluster configuration, upgrade and restore runbooks, dashboards and named owners for workflows, workers and the service.
