Skip to main content

Overview

Introduction to Temporal Nexus​

Temporal Nexus is a feature of the Temporal platform designed to connect durable executions across team, Namespace, region, and cloud boundaries. It promotes a more modular architecture for sharing a subset of your team’s capabilities via well-defined service API contracts for other teams to use, that abstract underlying Temporal primitives, like Workflows, or execute arbitrary code.

Temporal keeps the runtime benefits of an Event-Driven Architecture (EDA) where services can be down without affecting each other, but offers a higher-level durable execution programming model that lets you write idiomatic code in any language and preserve the state of execution so it can be resumed automatically in the presence of failure, without the extensive boilerplate code and complexity that comes with using raw EDA frameworks directly.

With Temporal Nexus, inter-service communication and durable execution may now span teams, Namespaces, and regions all from within the Temporal context. Nexus preserves a familiar API programming model that supports both sync and async patterns, is suitable for low-latency and long-running operations, and uses an optimized form of the Temporal queue-based worker architecture to preserve the benefits of EDA at runtime.

Temporal Nexus provides an integrated Temporal SDK experience, built-in Nexus Machinery, first-class observability, and enables each team to have their own Namespace for improved security, troubleshooting, and blast radius isolation.

Temporal Nexus overcomes these challenges with an integrated Temporal experience:

  • Fully integrated Temporal SDK experience
    • Run Nexus Services in a Worker, often the same Worker as underlying primitives
    • Use Nexus Services from a Workflow
    • Same queue-based Worker architecture, for Worker fleet load balancing
  • Built-in Nexus machinery
    • Connects Nexus callers and handlers via Nexus Endpoints
    • Automatic retries & circuit breaking
  • Multi-region routing across Namespaces
    • Secure mTLS connectivity
    • Endpoint access control
  • Observability
    • Integrated into Workflow Event History
    • Bi-direction linking for end-to-end debugging
    • Metrics, traces, and logs
  • Improved blast radius isolation
    • Each team can have it’s own Namespace
    • Per-Namespace security & rate limits
    • Easier troubleshooting with less noise

Key Considerations for Using Nexus​

  • Modular design - Temporal Nexus enables a modular design that helps structure an application for fast growth and support teams working on their own parts independently. If you want to decouple callers from handlers to enable moving a service to a different Namespace or Task Queue later, Nexus can encapsulate those implementation details to avoid breaking changes and cross-team coordination.

  • Teams working together - When there is no clear API contract between teams working in a large monolithic Namespace, it takes work to understand what Workflows can be called from other Workflows – or if a team has signed up to maintain that interface. This places a burden on both teams, and makes changes more difficult. Nexus Services define a clear contract that is suitable for sharing across teams, and cleanly separates the public interface from the internal implementation, providing a more curated experience for service consumers while protecting service authors.

  • Keeping things separate and secure - When all teams operate in the same monolithic Namespace, everything is available to everyone, and mis-behaving workers can trigger rate limits that affect all teams operating in that monolithic Namespace. Temporal Nexus enables service modules to run in arbitrary Namespaces, since all Nexus requests are routed via the Nexus Endpoint to the underlying target Namespace and Task Queue. Running a Nexus Service in its own Namespace allows tighter Namespace permissions and limits the blast radius of misbehaving workers.

  • Managing interactions across boundaries - When no clean boundary exists it is hard to manage concerns like security and rate-limiting. A Nexus Endpoint is similar to an API Proxy or Gateway, that can act as a central point of control for these concerns. Temporal Cloud supports built-in rate-limiting and an Endpoint allowlist - with a roadmap to support finer-grained rate-limiting and access-control policies suitable for external callers.

  • Adapting as the application grows - Temporal Nexus enables a modular application design that can evolve as you grow. From refactoring service implementations, changing an endpoint to point at a different target Namespace, or splitting a Worker out to a different Task Queue, Temporal Nexus enables you to hide these implementation details and provide a curated Nexus Service contract for other teams to use, so you can grow your application faster with less breaking changes, downtime, and cross-team coordination.

Key Capabilities of Temporal Nexus​

  • Connect durable execution within and across Namespaces
  • Service contracts suitable for sharing across teams
  • Abstract underlying Temporal primitives, like Workflows – or execute arbitrary code.
  • Modular design that streamlines multi-team development
  • Improved security and blast-radius isolation with isolated Namespaces
  • Same queue-based Worker architecture, no bespoke service deployments needed