namespaces

15 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Default Namespace behavior

If no Namespace is specified, the Temporal Service uses the Namespace 'default' for all Temporal SDKs and the Temporal CLI. You must create a Namespace before using it in your Client.

Multi-tenancy within a single Namespace

A single Namespace is still multi-tenant. Multiple applications or teams can share a Namespace, but must coordinate on Workflow ID and Task Queue naming to avoid conflicts.

Task Queues and Workflow Executions belong to Namespaces

Task Queues and Workflow Executions belong to a Namespace. When a Workflow Execution is spawned, it does so within a specific Namespace.

Temporal Cloud namespace additional capabilities

Temporal Cloud namespaces include additional capabilities such as API key and mTLS authentication, built-in role-based access controls, high availability replication, and namespace tags.

Zero downtime migration between self-hosting and Cloud

Moving from self-hosting to Cloud, or the reverse, requires zero code changes and incurs zero downtime.

Resource isolation in Namespaces

Heavy traffic from one Namespace will not impact other Namespaces running on the same Temporal Service.

Namespace-level configuration

Options like the Retention Period and Archival destination are configured per Namespace.

Workflow ID uniqueness within Namespace

Temporal guarantees a unique Workflow ID within a Namespace. Workflow Executions may have the same Workflow ID if they are in different Namespaces.

Nexus namespace isolation

Each team gets their own Namespace for security and fault isolation while exposing a clean service contract for others to use through a Nexus Endpoint.

Retention Period definition

Retention Period is the duration for which the Temporal Service stores data associated with closed Workflow Executions on a Namespace in the Persistence store. A Retention Period applies to all closed Workflow Executions within a Namespace and is set when the Namespace is registered. The Temporal Service triggers a Timer task at the end of the Retention Period that cleans up the data associated with the closed Workflow Execution on that Namespace.

Retention Period minimum and maximum

The minimum Retention Period is 1 day. On Temporal Service version 1.18 and later, the maximum Retention Period value for Namespaces can be set to anything over the minimum requirement of 1 day, but ensure that the Persistence store has enough capacity for the storage. On Temporal Service versions 1.17 and earlier, the maximum Retention Period is 30 days. Setting the Retention Period to 0 results in the error 'A valid retention period is not set on request'.

Retention Period default value

If the Retention Period value is not set when using the 'temporal operator namespace create' command, it defaults to 3 days. If the Retention Period value is not set when using the Register Namespace Request API, it returns an error.

Retention Period change behavior

When changing the Retention Period (with 'temporal operator namespace update' or the 'UpdateNamespace' API), the new duration applies to Workflow Executions that close after the change is saved. Changing the Retention Period does not affect existing closed Workflow Executions; they retain their original cleanup timers based on the Retention Period that was in effect when they closed.

Manual cleanup of closed Workflow Executions

For cases where closed Workflow Executions need to be removed before their retention timer expires, use 'temporal workflow delete' or the 'DeleteWorkflowExecution' command. This is particularly useful along with reducing the Retention Period to clean up previously closed Workflow Executions to reduce storage costs.

temporal CLI global flags - namespace and identity

Global flags for temporal CLI namespace and identity: --namespace/-n (string, optional, default default): Temporal Service Namespace.

Give your agent this brain