pattern @backend-architecture/pattern-service-registry

Service Registry

In a dynamic environment (containers come and go, instances autoscale), service hostnames are not known ahead of time.…

Skill: @backend-architecture
Domain: backend-architecture
Version: 1.0.0
Quality: 4.0
Edges: 3 out · 3 in
Tokens: 100/334/569

$ prime install @backend-architecture/pattern-service-registry

Projection

3 levels · agent picks one per query

Always in _index.xml · the agent never has to ask for this.

ServiceRegistry [pattern] v1.0.0

In a dynamic environment (containers come and go, instances autoscale), service hostnames are not known ahead of time. A service registry is the source of truth for 'which instances of service X are alive right now and at what addresses?'. Clients query the registry (or a router queries it) to resolve a service name to an instance.

Loaded when retrieval picks the atom as adjacent / supporting.

ServiceRegistry [pattern] v1.0.0

Label

Service Registry — runtime catalog of service instances and locations

Problem

Hard-coding hostnames or IPs of downstream services breaks the moment instances are recreated. A static load balancer config rots fast in an autoscaled fleet. The system needs a way to discover live instances dynamically.

Solution

    Run a registry (Consul, etcd, Eureka, Kubernetes' built-in, etc.):

      - Each service instance, on startup, registers (name, host:port, health-check URL).
      - Each instance heartbeats; the registry deregisters dead instances.
      - Clients (or a sidecar / load balancer) ask the registry: "Where is order-service?"
      - The registry returns a healthy instance list.

    Two discovery styles:
      - Client-side: the caller library queries the registry and load-balances.
      - Server-side: a router (envoy, NGINX-plus, k8s service) queries the registry; clients hit a stable VIP.

Loaded when retrieval picks the atom as a focal / direct hit.

ServiceRegistry [pattern] v1.0.0

Label

Service Registry — runtime catalog of service instances and locations

Problem

Solution

    Run a registry (Consul, etcd, Eureka, Kubernetes' built-in, etc.):

      - Each service instance, on startup, registers (name, host:port, health-check URL).
      - Each instance heartbeats; the registry deregisters dead instances.
      - Clients (or a sidecar / load balancer) ask the registry: "Where is order-service?"
      - The registry returns a healthy instance list.

    Two discovery styles:
      - Client-side: the caller library queries the registry and load-balances.
      - Server-side: a router (envoy, NGINX-plus, k8s service) queries the registry; clients hit a stable VIP.

Label

Service Registry — runtime catalog of service instances and locations

Problem

Solution

    Run a registry (Consul, etcd, Eureka, Kubernetes' built-in, etc.):

      - Each service instance, on startup, registers (name, host:port, health-check URL).
      - Each instance heartbeats; the registry deregisters dead instances.
      - Clients (or a sidecar / load balancer) ask the registry: "Where is order-service?"
      - The registry returns a healthy instance list.

    Two discovery styles:
      - Client-side: the caller library queries the registry and load-balances.
      - Server-side: a router (envoy, NGINX-plus, k8s service) queries the registry; clients hit a stable VIP.

Source

where the compiled artifact came from

prime-system/examples/backend-architecture/primes/compiled/@backend-architecture/pattern-service-registry/atom.yaml

Compiled at 2026-05-10