Central Registry¶

Service directory — instantiates Request–Response Capability Provisioning

A single authoritative directory that maps a capability's name to where it lives and how to call it, so clients discover and bind to the provider by lookup instead of hard-wiring its location.

Before a client can send a request, it has to know where the capability is and how to call it — and if every client hard-codes that, the provider can never move, replicate, or be replaced without breaking them all. Central Registry is the indirection that removes the hard-coding: a single authoritative directory that maps a stable name to the provider's current address and calling contract. Clients resolve the name at request time instead of knowing a location; the registry's defining job is to be the one place that answers "where is X, and how do I talk to it?" so that identity is decoupled from location.

Example¶

A materials-science campus shares expensive instruments across dozens of labs. Rather than each lab keeping tribal knowledge of who runs what, the facility maintains a central registry of capabilities. A lab that needs an electron-microscope run queries it and gets back: SEM-2 — operated by the Nanofab Core; book through the Core's intake endpoint; samples must be under one centimetre and conductive. That single entry gives the requesting lab the address (where to send the request) and the interface contract (what a valid request must satisfy). When SEM-2 is retired and replaced by a newer instrument in a different building, only the registry entry changes — every lab keeps looking up the same capability name and is transparently routed to the new provider. The registry did the addressing; it never ran a single sample itself.

How it works¶

What distinguishes a registry from an ordinary list is that it is a live source of truth about reachability:

Providers register their capability under a stable name, publishing address, calling contract, version, and ownership.
The registry is the single authority for where each capability lives and how to reach it — one answer, not a dozen stale copies.
Clients resolve the name at request time (often caching the result under a short lifetime) rather than embedding a location.
Entries stay fresh through renewal or heartbeat, so a provider that dies ages out instead of luring clients to a dead address.

The core move is indirection: a layer of names that can be repointed without touching any client, exactly as DNS does for hostnames.

Tuning parameters¶

Freshness model (TTL / heartbeat) — how fast stale entries expire. Short lifetimes keep answers accurate but make lookups chattier; long ones are cheap but risk pointing at a departed provider.
Consistency versus availability — a strongly-consistent registry never returns a stale address but can refuse to answer under partition; an eventually-consistent one always answers but may lag reality.
Metadata richness — name-to-address only, versus name-to-address-plus-contract-plus-version-plus-health. Richer entries enable smarter binding but cost more to keep current.
Registration authority — self-registration by providers (scalable) versus curated, approved entries (trustworthy).
Client-side caching — resolve every call versus cache with a TTL. Caching cuts registry load but must honour expiry to avoid binding to a stale address.

When it helps, and when it misleads¶

Its strength is decoupling: clients depend on a name, not a location, so the provider can move, scale out, or be swapped with no client changes, and there is one authoritative answer instead of scattered tribal knowledge. The failure modes are the price of centralization. The registry is itself a shared dependency and a potential single point of failure — if lookup is down, nothing new can bind. And a stale entry is worse than no entry: it confidently routes a client to a provider that has moved or died. Under a network partition the registry faces the consistency-versus-availability choice directly^[1]. The discipline is to make entries self-expiring via heartbeat, replicate the registry itself, and have clients treat a resolved address as a hint to be re-resolved on failure rather than a permanent truth.

How it implements the components¶

Central Registry fills the discovery subset of the archetype's machinery — the components that let a client find and bind to the capability:

registry — its core: the authoritative name-to-provider directory itself.
addressable_service_endpoint — it produces addressability by resolving a stable name to the provider's current endpoint, the indirection that makes the capability reachable without hard-coding.
interface_contract — each entry publishes the capability's calling contract and version, so a client discovers not just where to call but how.

It does not receive or answer the actual request — the live endpoint is API or RPC Endpoint; it does not authenticate callers (Authentication Broker) or de-duplicate requests (Idempotent API).

Instantiates: Request–Response Capability Provisioning — it supplies the addressability and discovery that let many independent clients locate and bind to the shared provider.
Sibling mechanisms: API or RPC Endpoint · Authentication Broker · Idempotent API · Safe Retry Protocol · Autoscaling Worker Pool · Parallel Server Activation · Rate Limit with Burst Allowance · Weighted Fair Queue · Service-Level Agreement · Service-Level Monitor · Intake Portal · Shared Service Desk · Ticketing System · Cache or Read Replica

Notes¶

A registry that maps only name-to-address, with no health or expiry, silently rots: providers come and go while the directory keeps handing out addresses that used to be valid. The freshness mechanism — heartbeat and TTL — is not decoration but the thing that separates a live directory from a confidently-wrong one.

References¶

[1] The CAP theorem (Brewer): under a network partition a replicated store must choose between consistency and availability. A registry that favours availability may return stale addresses; one that favours consistency may decline to answer — the right choice depends on how damaging a stale binding would be. ↩