Temporal

Executes workflow code as a series of deterministic steps with automatic state persistence and recovery. Uses event sourcing via the History Service to store all workflow decisions and events in an immutable event log, enabling workers to replay execution history and recover from failures without re-executing completed steps. The Mutable State Management system tracks workflow progress across shards, and the History Engine reconstructs state by replaying events up to the failure point.

Wraps external service calls (HTTP APIs, database queries, ML model inference) as Activities — isolated, non-deterministic operations that run on workers and report results back to the workflow. The Matching Service routes activity tasks to available workers via task queues, and the History Service tracks activity completion. Built-in retry policies (exponential backoff, max attempts, jitter) and timeout enforcement (start-to-close, schedule-to-start, heartbeat) are applied automatically without workflow code changes.

Automatically archives completed workflow histories to a long-term storage backend (S3, GCS, or database) after a retention period. The Archiver Service runs as a background process and moves histories from the main event log to archive storage, freeing up database space. Archived histories can be retrieved via the Temporal API for auditing or compliance purposes, though with higher latency than active histories.

Emits detailed metrics (latency, throughput, error rates) and structured logs for all Temporal operations. Metrics are tagged with service, operation, and namespace for fine-grained analysis. The system integrates with OpenTelemetry for distributed tracing, enabling end-to-end visibility of workflow execution across services. Metrics are exported to monitoring systems (Prometheus, Datadog, CloudWatch) via configurable exporters.

Enables workflows in one cluster to invoke operations (workflows or activities) in another cluster or namespace via the Nexus protocol. Nexus operations are asynchronous and return a handle that can be awaited for results. The Frontend Service routes Nexus requests to the target cluster, and the History Service tracks the async operation. This enables federated workflow systems where workflows can span multiple clusters.

Enables runtime configuration changes without restarting the Temporal server via a dynamic configuration system. Configuration values (timeouts, quotas, feature flags) are stored in the database and polled by services at regular intervals. Changes take effect within seconds. The system supports per-namespace and per-workflow-type overrides, enabling fine-grained control.

Provides a built-in Scheduler Workflow that enables recurring workflow execution (cron-like schedules) and delayed execution without requiring external schedulers. Schedules are defined with cron expressions or interval-based patterns, and the Scheduler Workflow automatically spawns workflow executions at the scheduled times. Supports timezone-aware scheduling, backfill for missed executions, and pause/resume of schedules.

Routes workflow and activity tasks to workers via named task queues managed by the Matching Service. Workers poll task queues and execute tasks; the Matching Service maintains a registry of available workers per queue and distributes tasks fairly. Worker Versioning enables gradual rollouts: new worker versions are tagged, and the server can route tasks to specific versions or gradually shift traffic from old to new versions, enabling zero-downtime deployments.

Allows external systems to send Signals (asynchronous notifications) and Updates (synchronous requests with responses) to running workflows without stopping them. Signals are queued and processed by the workflow at safe points; Updates block the caller until the workflow processes the request and returns a result. The History Service records all signals and updates in the event log, ensuring they survive worker failures and are replayed correctly.

Replicates workflow state and history across multiple datacenters using the Replication System. The History Service streams events to replica clusters in near-real-time; if the primary cluster fails, clients can failover to a replica cluster and resume workflows. Namespace-level replication policies control which clusters receive updates and in what order, enabling active-passive or active-active topologies.

Partitions workflows, activities, and task queues into isolated namespaces, enabling multi-tenant deployments. Each namespace has its own event history, visibility store, and configuration. The Frontend Service enforces namespace isolation via request interceptors, and dynamic configuration enables per-namespace quotas (max concurrent workflows, max task queue depth, rate limits). Namespaces can be replicated independently, supporting per-tenant disaster recovery policies.

Indexes workflow executions in a Visibility Store (separate from the main event log) with searchable fields (workflow type, status, start time, custom attributes). The Frontend Service exposes a ListWorkflowExecutions API that supports SQL-like queries (e.g., 'WorkflowType = "payment" AND Status = RUNNING AND StartTime > now - 1h'). Visibility data is eventually consistent with the main event log, updated asynchronously by the Worker Service.

Enables safe code changes to workflows via versioning primitives (GetVersion() API) that allow workflows to execute different code paths based on version. When workflow code changes, new executions use the new code, while in-flight executions continue with the old code path until they complete. The History Service replays events with the correct version context, ensuring determinism. This eliminates the need to wait for all in-flight executions to complete before deploying.

Provides a built-in Scheduler Workflow that executes other workflows on a schedule (cron-like) or with a delay. The Scheduler Workflow runs continuously and spawns child workflows at specified intervals or times. Schedules are stored in the Temporal database and survive server restarts. The Worker Service manages schedule execution, ensuring that missed schedules are caught up when the server recovers.

Provides batch APIs to perform operations on multiple workflows in bulk: cancel, terminate, or signal multiple workflows matching a query. The Frontend Service processes batch requests by querying the Visibility Store for matching workflows and then issuing individual operations. Batch operations are asynchronous and return a job ID for tracking progress.