new·Earn with mozg — 20% of every monthSend somebody here and take a fifth of every plan payment they make, for as long as they keep paying — not a bounty on the first invoice. Your handle is the link, the window is thirty days, and the commission lands on your balance the second they pay. Free to join: if you have signed in, you already have the link. mozg.sh/earnall news →
mozg.beta
Sign in

Temporal · Concepts · all subjects

architecture/infrastructure

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

Pre-release dev server setup for Standalone Nexus Operations

The Pre-release dev server enables Standalone Nexus Operations by default with no dynamic config required. Start the server with temporal server start-dev and specify caller and handler Namespaces using --namespace flags. The starter and Worker connect to two different Namespaces (a caller Namespace and a handler Namespace), mirroring how Nexus crosses Namespace boundaries.

Standalone Nexus Operations with Temporal Cloud compatibility

The same code works against Temporal Cloud without code changes. Configure the connection via environment variables or a TOML profile using envconfig.MustLoadDefaultClientOptions(). Full details on connecting to Temporal Cloud include Namespace creation, Nexus Endpoint setup, certificate generation, and authentication options.

Temporal Cloud pricing components

Temporal Cloud uses consumption-based pricing with two primary cost components: Actions and Storage.

Cost distribution in Temporal workloads

For most workloads, Actions represent the majority of total costs, with storage typically accounting for 10% or less of a monthly bill.

High Actions costs indicators

High Actions costs generally indicate: many Activities per Workflow, frequent Signals/Queries/Updates, long-running Activities with Heartbeats, high Activity retry rates, or extensive Query usage.

High Storage costs indicators

High Storage costs generally indicate: large payloads in Workflow inputs, outputs, or Activity results; long retention periods with high Workflow volume; long-running Workflows without Continue-As-New; or Workflows accumulating large Event Histories.

Optimization priority order

Optimization priority should follow this order: 1) Actions optimization (usually provides largest cost reduction opportunity), 2) Active Storage optimization (relevant for long-running Workflows or large payloads), 3) Retained Storage optimization (relevant for high volume combined with long retention periods).

Child Workflows cost vs Activities

Child Workflows cost 2 Actions compared to an Activity's 1 Action.

Search Attributes billing for inputs

Search Attributes provided at Workflow start do not count as billable Actions. If Search Attribute values are known before starting the Workflow, provide them at Workflow start to eliminate these costs entirely.

UpsertSearchAttributes Action consumption

Each UpsertSearchAttributes call counts as 1 Action regardless of how many attributes are updated.

Signal batching optimization

Batch multiple related attribute updates into single UpsertSearchAttributes operations to reduce Actions consumed.

SignalWithStart vs separate calls

Use SignalWithStart instead of separate StartWorkflow and SignalWorkflow calls when initiating Workflows with Signals to reduce billable Actions.

Active Storage vs Retained Storage cost difference

Active Storage (open Workflows) is significantly more expensive than Retained Storage (closed Workflow History during retention period).

Compression for Active Storage optimization

Large payloads increase Active Storage costs. Implement a custom Data Converter with compression for moderately large payloads (100KB-1MB).

Workflow export Action consumption

Workflow export costs one Action per export.

Workflow export use case

Temporal Cloud supports exporting Event Histories to external storage for compliance while maintaining shorter retention periods.

Validation approach for optimizations

When validating optimizations: test in non-production to validate functional correctness before production deployment, monitor comprehensively using the Usage dashboard in the Cloud UI to track impact on Actions and Storage, deploy progressively to a small percentage and validate before expanding, and re-evaluate optimization effectiveness quarterly as system evolves.

Optimization success criteria

Optimization success criteria include: cost reduced without increasing mean time to repair (MTTR), Workflow success rates maintained or improved, and reduced observability not increasing mean time to detect (MTTD) incidents.

Baseline metrics to establish before optimizing

Establish baseline metrics before optimizing: Actions consumption (per Workflow, per day/month, by Namespace), Storage consumption (Active and Retained), monthly costs (total, per Namespace, per Workflow Type), and observability metrics (time to debug, incident detection).

Give your agent this brain