Temporal architecture: Client, Server, Worker separation
In a Temporal application, the Temporal Client, Temporal Server, and Worker are three separate parts that communicate over the network. The Client sends control requests such as starting a Workflow, sending a Signal, or requesting a result. The Server records Event History, schedules Tasks on Task Queues, and persists state to a database. The Worker polls Task Queues and runs Workflow and Activity code. The Client does not execute Workflow or Activity code. The Server does not run application code directly.
Durable execution mechanism
The Server records all state and creates Workflow and Activity Tasks in Task Queues. Workers poll those queues, run Workflow and Activity code, and send back Commands and results. The Server uses this information to update the Event History so that any Client can later request the current status or the final result, and execution can safely continue (or replay) even if individual Worker processes or machines fail.
Temporal does not run application code in the Server
Temporal explicitly does not run Workflow or Activity code inside the Server; that code only runs in Workers, which are under user control.
Temporal provides Durable Execution despite infrastructure issues
Temporal's Durable Execution guarantees that applications run to completion despite infrastructure issues, network problems, and Worker crashes. However, not all failures are handled automatically by the platform.
Temporal documentation structure
The Temporal documentation is organized into several main sections: Encyclopedia (which covers concepts and components), Develop (which covers implementation of developer-facing features), Temporal Cloud production deployment, Self-hosted production deployment, and a Glossary for complete terminology.
Temporal purpose
Temporal provides developers a suite of effective tools for building reliable applications at scale.
Temporal Encyclopedia main topics
The Temporal Encyclopedia covers key concepts and components including: Temporal, Temporal architecture, Temporal SDKs, Temporal Client, Workflows, Activities, Failures and error handling, Workers, Event History, Workflow Message Passing, Child Workflows, Visibility, Temporal Service, Namespaces, Temporal Nexus, and Extensibility.
Global Namespace failover version purpose
A Global Namespace has a failover version. The failover version prevents certain conflicts from occurring if a failover is mistakenly triggered simultaneously on two Clusters. Because a failover can be triggered from any Cluster, the failover version serves as a safeguard against race conditions.
Global Namespace definition and basic properties
A Global Namespace is a Namespace that exists across Clusters when Multi-Cluster Replication is set up. A Global Namespace may be replicated to any number of Clusters, but is active in only one Cluster at any given time.
NamespaceNotActiveError on non-active cluster
Temporal Application API calls made to a non-active Cluster are rejected with a NamespaceNotActiveError, which contains the name of the current active Cluster. It is the responsibility of the Temporal Application to call the Cluster that is currently active.
Namespace definition and purpose
A Namespace is a unit of isolation within the Temporal Platform that provides resource separation, Workflow ID uniqueness, and configuration boundaries.
Nexus overview and purpose
Nexus connects Temporal Applications across isolated Namespaces with clean service contracts. It lets teams selectively expose functionality without exposing internal implementation details, enabling code reuse and building a more modular platform. Nexus is designed for Durable Execution with built-in observability and security.
Nexus is peer-to-peer, not hierarchical
Caller and handler Workflows are siblings that communicate across Namespace boundaries through Nexus. The architecture is peer-to-peer rather than hierarchical.
Temporal Service definition and components
A Temporal Service is the group of services known as the Temporal Server, combined with Persistence and Visibility stores. Together these components act as a single component of the Temporal Platform. The term 'Temporal Cluster' has been replaced with 'Temporal Service' in current terminology.
Temporal Server maintenance support policy
Temporal offers maintenance support of the last three minor versions after a release and does not plan to backport patches beyond that. Major versions are supported for at least 12 months after a GA release, with at least 6 months' notice before EOL/deprecating support. Maintenance support includes critical bug fixes related to security, prevention of data loss, and reliability.
Temporal Server dependency support
Temporal offers official support for and is tested against dependencies with the exact versions described in the go.mod file of the corresponding release tag.
Temporal Server four main services
The Temporal Server consists of four independently scalable services: Frontend gateway (for rate limiting, routing, authorizing), History subsystem (maintains data including mutable state, queues, and timers), Matching subsystem (hosts Task Queues for dispatching), and Worker Service (for internal background Workflows).
Temporal Server service scaling and deployment
The History, Matching, and Worker Services can scale horizontally within a Temporal Service. The Frontend Service scales differently because it has no sharding or partitioning; it is stateless. For production environments, each service should run independently to ensure different scaling requirements can be met and troubleshooting becomes easier. Each service is aware of others through a membership protocol via Ringpop.
SDK and Server version support
All SDK versions support all server versions. SDKs and Temporal Server are released independently of one another. To take advantage of bug fixes, performance improvements, and new features, both SDK and servers should be upgraded to the latest versions on a regular cadence.
Temporal Server upgrade path support
Temporal supports upgrade paths from every version beginning with Temporal v1.7.0. The documentation provides maintenance support information on upgrading Temporal Service.
Temporal is a durable execution platform
Temporal is a scalable and reliable runtime for durable function executions called Temporal Workflow Executions. It is a platform that guarantees the Durable Execution of application code, enabling code to run reliably even in the face of failures like network outages or server crashes.
Temporal Platform components
The Temporal Platform consists of two main components: the Temporal Service (supervising software) and Worker Processes (application code). The Temporal Service consists of the Temporal Server, written in Go, and a database. Worker Processes are hosted and operated by the user and execute application code using one of the Temporal SDKs. Together these components create a runtime for a Temporal Application.
Temporal Application definition
A Temporal Application is a set of Temporal Workflow Executions. Each Temporal Workflow Execution has exclusive access to its local state, executes concurrently to all other Workflow Executions, and communicates with other Workflow Executions and the environment via message passing.
Schedule implementation as Workflow
Internally, a Schedule is implemented as a Workflow. If you're using Elasticsearch, these Workflow Executions are hidden from normal views.
Temporal SDK definition and purpose
A Temporal SDK is an open-source library you add to your application to use Temporal. It provides everything needed to build Workflows, Activities, and other Temporal features in a specific programming language, including APIs to configure a Temporal Client, develop your Temporal Application, and run Workers you can scale out as your load grows.
Temporal Application definition
A Temporal Application is the code written by developers comprised of Workflow Definitions, Activity Definitions, code used to configure Temporal Clients, and code used to configure and start Workers. Workflow Definition code can be executed repeatedly, with the Temporal Platform supporting millions to billions of Workflow Executions concurrently. A Temporal Application can run for seconds or years in the presence of arbitrary load and failures.
Temporal SDK major components
Temporal SDKs offer three major components: (1) a Temporal Client to communicate with a Temporal Service, (2) APIs to develop application code (Workflows & Activities), and (3) APIs to configure and run Workers.
Workflow code execution characteristics
Workflow code, while executing, can be paused, resumed, and migrated across physical machines without losing state. When a Workflow calls the API to execute an Activity, the Worker sends a Command back to the Temporal Service. The Temporal Service creates Activity Tasks in response which the same or a different Worker can then pick up and begin executing. The state of the Workflow is automatically persisted so if a failure occurs, it resumes right where it left off.
SDK benefits for fault-tolerance
Temporal SDKs empower developers to concentrate on creating dependable and scalable business logic, alleviating the need to build home-grown supervisor systems to ensure reliability and fault-tolerance. For instance, Temporal SDKs have built-in support for handling failures, timeouts, and retries. In the event of an Activity failure, the SDK automatically initiates retries according to configurable policies established by the developer within the SDK.
SDK abstraction level for business logic
The level of abstraction that SDK APIs offer enables the developer to focus on business logic without having to worry about the intricacies of distributed computing such as retries, or having to explicitly maintain a state machine and the intermediate state for each step of the process. The SDK APIs enable developers to write code that more genuinely maps to their process by reducing boilerplate code.
Workflow Definition, Type, and Execution relationship
A Workflow Definition is the code that defines a Workflow. A Workflow Type is the name that maps to a Workflow Definition and serves as an identifier to distinguish one type of Workflow from another, such as order processing versus customer onboarding. A Workflow Execution is a running Workflow created by combining a Workflow Definition with a request to execute it. A single Workflow Definition can be executed any number of times with different inputs, with each execution being an actual instance of the Workflow Definition running in the Temporal Platform.
Workflow resilience and automatic recovery
Temporal Workflows are resilient and can run for years even if the underlying infrastructure fails. If the application itself crashes, Temporal will automatically recreate its pre-failure state so it can continue right where it left off.
Workflow code execution and development
Workflows are developed by writing code in a general-purpose programming language such as Go, Java, TypeScript, or Python. The code you write is the same code that will be executed at runtime, so you can use your favorite tools and libraries to develop Temporal Workflows.