new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Temporal · all subjects

platform

106 notes in this subject, read out of this brain and free to use. This is page 1 of 2.

Namespace

A Namespace is a unit of isolation within the Temporal Platform.

Temporal Platform

The Temporal Platform consists of a Temporal Service and Worker Processes.

Temporal Service

A Temporal Service is a Temporal Server paired with Persistence and Visibility stores.

Temporal Server

The Temporal Server is a grouping of four horizontally scalable services.

Frontend Service

The Frontend Service is a stateless gateway service that exposes a strongly typed Proto API. The Frontend Service is responsible for rate limiting, authorizing, validating, and routing all inbound calls.

History Service

The History Service is responsible for persisting Workflow Execution state and determining what to do next to progress the Workflow Execution through History Shards.

Matching Service

The Matching Service is responsible for hosting external Task Queues for Task dispatching.

Replication Lag

Replication Lag is the transmission delay of Workflow updates and history events from the active region to the standby region.

Multi-Cluster Replication

Multi-Cluster Replication is a feature which asynchronously replicates Workflow Executions from active Clusters to other passive Clusters, for backup and state reconstruction.

Dual Visibility

Dual Visibility is a feature, specific to a Self-hosted Temporal Service, that lets you set a secondary Visibility store in your Temporal Service to facilitate migrating your Visibility data from one database to another.

Archival

Archival is a feature specific to a Self-hosted Temporal Service that automatically backs up Event Histories from Temporal Service persistence to a custom blob store after the Closed Workflow Execution retention period is reached.

Retention Period

A Retention Period is the amount of time a Workflow Execution Event History remains in the Temporal Service's persistence store.

Temporal SDK

A Temporal SDK is a language-specific library that offers APIs to construct and use a Temporal Client to communicate with a Temporal Service, develop Workflow Definitions, and develop Worker Programs.

Temporal Client

A Temporal Client, provided by a Temporal SDK, provides a set of APIs to communicate with a Temporal Service.

Core SDK

The Core SDK is a shared common core library used by several Temporal SDKs. Written in Rust, the Core SDK provides complex concurrency management and state machine logic among its standout features. Centralizing development enables the Core SDK to support quick and reliable deployment of new features to existing SDKs, and to more easily add new SDK languages to the Temporal ecosystem.

Temporal Application

A Temporal Application is a set of Workflow Executions.

Temporal Web UI

The Temporal Web UI provides users with Workflow Execution state and metadata for debugging purposes.

Workflow History Export

Workflow History export allows users to export Closed Workflow Histories to a user's Cloud Storage Sink.

Tag

A Tag is a key-value pair that a Temporal SDK or the Temporal Service attaches to an emitted metric, such as namespace or task_queue. Once a metric is scraped by Prometheus or another OpenMetrics-compatible system, the same key-value pair is called a label.

Temporal Service configuration

Temporal Service configuration is the setup and configuration details of your Temporal Service, defined using YAML.

Worker Service

The Worker Service runs background processing for the replication queue, system Workflows, and (in versions older than 1.5.0) the Kafka visibility processor.

History Shard

A History Shard is an important unit within a Temporal Service by which the scale of concurrent Workflow Execution throughput can be measured.

Temporal Cloud

Temporal Cloud is a managed, hosted Temporal environment that provides a platform for Temporal Applications.

Temporal Cloud Namespace Name

A Cloud Namespace Name is a customer-supplied name for a Namespace in Temporal Cloud.

Temporal Cloud Namespace Id

A Cloud Namespace Id is a globally unique identifier for a Namespace in Temporal Cloud.

Temporal Cloud Account Id

A Temporal Cloud Account Id is a unique identifier for a customer.

Temporal Cloud gRPC Endpoint

A Cloud gRPC Endpoint is a Namespace-specific address used to access Temporal Cloud from your code.

Action

An Action is the fundamental pricing unit in Temporal Cloud. Temporal Actions are the building blocks for Workflow Executions. When you execute a Temporal Workflow, its Actions create the ongoing state and progress of your Temporal Application.

Actions Per Second (APS)

APS, or Actions per second, is specific to Temporal Cloud. Each Temporal Cloud Namespace enforces a rate limit, which is measured in Actions per second (APS). This is the number of Actions, such as starting or signaling a Workflow, that can be performed per second within a specific Namespace.

Requests Per Second (RPS)

RPS, or Requests per second, is used in the Temporal Service (both in self-hosted Temporal and Temporal Cloud). This is a measure that controls the rate of requests at the service level, such as the Frontend, History, or Matching Service.

Visibility

The term Visibility, within the Temporal Platform, refers to the subsystems and APIs that enable an operator to view Workflow Executions that currently exist within a Temporal Service.

Search Attribute

A Search Attribute is an indexed name used in List Filters to filter a list of Workflow Executions that have the Search Attribute in their metadata.

List Filter

A List Filter is the SQL-like string that is provided as the parameter to an advanced Visibility List API.

Global Namespace

A Global Namespace is a Namespace that duplicates data from an active Temporal Service to a standby Service using replication to keep both Namespaces in sync. Global Namespaces are designed to respond to service issues like network congestion. When service to the primary Cluster is compromised, a failover transfers control from the active to the standby cluster.

Failover

A failover shifts Workflow Execution processing from an active Temporal Namespace region to a standby Temporal Namespace region during outages or other incidents. Standby Namespace regions use replication to duplicate data and prevent data loss during failover.

Failback

After Temporal Cloud has resolved an outage or incident involving a failover, a failback process shifts Workflow Execution processing back to the original region that was active before the incident.

Availability Zone

An availability zone is a part of the Temporal system where tasks or operations are handled and executed. This design helps manage workloads and ensure tasks are completed. Temporal Cloud Namespaces are automatically distributed across three availability zones, offering the 99.9% uptime outlined in the Cloud SLA.

High Availability

High availability ensures that a system remains operational with minimal downtime. It achieves this with redundancy and failover mechanisms that handle failures, so end-users remain unaware of incidents. Temporal Cloud guarantees this high availability with its Service Level Agreements (SLA).

High Availability features

High Availability features automatically synchronize your data between a primary Namespace and its replica, keeping them in sync. In case of an incident or an outage, Temporal will automatically failover your Namespace from the primary to the replica. This supports high levels of business continuity, allowing Workflow Executions to continue with minimal interruptions or data loss.

Same-region Replication

Same-region Replication replicates Workflows and metadata to a separate cell within the same region as the primary Namespace. It provides a reliable failover mechanism while maintaining deployment simplicity.

Multi-region Replication

Multi-region Replication replicates Workflows and metadata to a different region that is not co-located with the primary Namespace. This is particularly beneficial for organizations with multi-regional architectures or those required to be highly available across regions for compliance purposes.

Multi-cloud Replication

Multi-cloud Replication replicates Workflows and metadata to a different cloud provider (AWS or GCP). This is particularly beneficial for organizations required to be highly available across regions for compliance purposes.

Nexus Operation

An arbitrary-duration operation that may be synchronous or asynchronous, short-lived, or long-lived, and used to connect durable executions within and across Namespaces, clusters, regions, and clouds. Unlike a traditional RPC, an asynchronous Nexus Operation has an operation token that can be used to re-attach to a long-lived Nexus Operation, for example, one backed by a Temporal Workflow. Nexus Operations support a uniform interface to get the status of an operation or its result, receive a completion callback, or cancel the operation – all of which are fully integrated into the Temporal Platform.

Nexus Service

A Nexus Service is a named collection of arbitrary-duration Nexus Operations that provide a microservice contract suitable for sharing across team and application boundaries. Nexus Services are registered with a Temporal Worker that is polling a Nexus Endpoint's target Namespace and Task Queue.

Nexus Operation Handler

The Nexus handler code in a Temporal Worker typically created using Temporal SDK builder functions that make it easy to abstract Temporal primitives and expose a clean service contract for others to use.

Nexus Endpoint

A Nexus Endpoint is a reverse proxy that can serve one or more Nexus Services. It routes Nexus requests to a target Namespace and Task Queue, that a Nexus Worker is polling. This allows service providers to present a clean service contract and hide the underlying implementation, which may consist of many internal Workflows. Multiple Nexus Endpoints can target the same Namespace.

Nexus Registry

The Nexus Registry manages Nexus Endpoints and provides lookup services for resolving Nexus requests at runtime. In the open source version of Temporal, the Registry is scoped to a Cluster, while in Temporal Cloud, it is scoped to an Account. Endpoint names must be unique within the Registry. When the Temporal Service dispatches a Nexus request, it resolves the request's Endpoint to a Namespace and Task Queue through the Registry.

Nexus RPC

Nexus RPC is a protocol designed with durable execution in mind. It supports arbitrary-duration Operations that extend beyond a traditional RPC — a key underpinning to connect durable executions within and across Namespaces, clusters, regions, and cloud boundaries.

Nexus Machinery

Temporal has built-in Nexus Machinery to guarantee at-least-once execution of Nexus Operations with state-machine-based invocation and completion callbacks. The Nexus Machinery uses Nexus RPC, a protocol designed with Durable Execution in mind, to communicate across Namespace boundaries. Caller Workflows and Nexus handlers don't have to use Nexus RPC directly, since the Temporal SDK provides a streamlined developer experience to build, run, and use Nexus Services.

Nexus Operation Events

Nexus Operations Events are history events that surface in the Caller Workflow to indicate the state of an Operation including Nexus Operation Scheduled, Nexus Operation Started, Nexus Operation Completed.

Nexus Async Completion Callback

A Nexus Async Completion Callback is the completion callback for an asynchronous Nexus Operation.

Nexus Service Contract

A common code package, schema, or documentation that a Caller can use to obtain Service and Operation names as associated input/output types a Service will accept for a given Operation.

Distributed lock prerequisites and versions

Required: Python 3.12 or later, Temporal Python SDK 1.7 or later, uv 0.9.18 for dependency management, Temporal CLI 1.6.2, and access to Temporal Cluster 1.3.2 (local development server or Temporal Cloud). For Temporal Cloud, an API key with Namespace Admin role for the target Namespace is required.

Temporal Cloud capacity modes and provisioned capacity

Temporal Cloud offers different capacity modes to accommodate varying workloads. When using provisioned capacity, you define the maximum throughput your Namespace can consume. Modifying this limit via an API call allows you to scale resources up for intensive tasks. The pattern demonstrates how to adjust capacity dynamically without manual operator intervention.

Prerequisites for temporary rate limit increases pattern

Required software: Temporal Go SDK v1.40.0 or later, Go v1.23 or later, Temporal CLI v1.6.1 or later. Required access: Temporal Cloud Account with Admin role for the target Namespace to access the Cloud Operations API, and a generated API key using your Temporal Cloud account. Required concepts: familiarity with Temporal Workflows, Activities, Child Workflows, Timers, Workers, and Cloud Namespaces.

Secondary visibility dynamic configuration keys

Secondary visibility configuration keys enable Dual Visibility on your Temporal Cluster, useful when migrating a Visibility database or creating a backup Visibility store. system.enableReadFromSecondaryVisibility (Boolean, default false) enables reading from the secondary visibility store and can be set per Namespace (allowed values: true or false). system.secondaryVisibilityWritingMode (String, default 'off') enables writing Visibility data to the secondary Visibility store and can be set per Namespace. Allowed values: 'off' (write to primary Visibility store only), 'on' (write to secondary Visibility store only), 'dual' (write to both primary and secondary Visibility stores).

Nexus dynamic configuration keys

Settings related to the management of Nexus: system.enableNexus (Boolean, default true since 1.27, removed in 1.31.0 as Nexus is always enabled) enables Nexus Features. component.nexusoperations.useSystemCallbackURL (String, default false, server 1.30 or newer) controls whether to use temporal://system as the callback URL generated by the server. component.nexusoperations.callback.endpoint.template (String, unset by default) defines the URL template used to construct Nexus callback URLs (only required for experimental external endpoint target feature or servers older than 1.30). component.callbacks.allowedAddresses (Object, unset by default) defines the security allow-list of callback URL patterns that the server will accept (only required for experimental external endpoint target feature or servers older than 1.30).

Dynamic configuration best practice: test before production

Setting dynamic configuration keys is optional. Change these values only if you need to override the default values to achieve better performance on your Temporal Cluster. Ensure that you test your changes before setting them in production. When scaling services and tuning RPS, test your workload and set acceptable provisioning benchmarks. When changing size limits, ensure you are provisioning enough database resources to handle the changed values.

Size limit dynamic configuration keys

Size and count limits for Persistence store operations: limit.maxIDLength (Int, default 1000) sets length limit for Namespace, TaskQueue, WorkflowID, ActivityID, TimerID, WorkflowType, ActivityType, SignalName, MarkerName, ErrorReason/FailureReason/CancelCause, Identity, and RequestID. limit.blobSize.warn (Int, default 512 KB) sets BLOB size limit for warning in server logs. limit.blobSize.error (Int, default 2 MB) sets BLOB size limit for error in transaction. limit.historySize.warn (Int, default 10 MB) sets Workflow Execution Event History size limit for warning. limit.historySize.error (Int, default 50 MB) sets Event History size limit for error. limit.historyCount.warn (Int, default 10,240 events) sets Event History event count limit for warning. limit.historyCount.error (Int, default 51,200 events) sets Event History event count limit for error.

Pending item and child workflow limit dynamic configuration keys

Limits for pending items in Workflow Executions: limit.numPendingActivities.error (Int, default 2000) sets maximum pending Activities before ScheduleActivityTask fails. limit.numPendingSignals.error (Int, default 2000) sets maximum pending Signals before SignalExternalWorkflowExecution commands fail. history.maximumSignalsPerExecution (Int, default 10000) sets maximum Signals a Workflow Execution can receive before Invalid Argument error. limit.numPendingCancelRequests.error (Int, default 2000) sets maximum pending cancel requests before RequestCancelExternalWorkflowExecution commands fail. limit.numPendingChildExecutions.error (Int, default 2000) sets maximum pending Child Workflows before StartChildWorkflowExecution commands fail.

Give your agent this brain