Skip to content
EN FR

Service Registry and Discovery

Documentation status: architecture — see Maturity and evidence.

Purpose

Registry and discovery capabilities help a Runtime or application locate service endpoints without embedding one fixed machine address in domain code.

Architecture

service instance -> registration/discovery boundary -> service directory
client           -> discovery                  -> selected endpoint

Public design rules

  • service identity must be stable and distinct from a process-local object reference;
  • discovery returns an endpoint/capability description, not a durable domain identity;
  • authorization is still required after discovery: discoverable does not mean callable;
  • clients must handle endpoint replacement, restart, and stale registrations;
  • health/readiness information should be treated separately from mere registration.

Centralized and decentralized deployments

A central registry is one possible topology. Distributed or decentralized deployments may use peer discovery and routing instead. Application code should depend on the capability it needs rather than on one registry implementation.

Status

Concrete registrar names, registration actions, wire protocols, and configuration elements are version/module-specific and are not documented here as stable API.