Service Registry

The CORE of service discovery: a database of (service_name, instance_id, address, health) tuples.

{
  "billing": [
    {"id": "i-1", "addr": "10.0.1.45:8080", "health": "alive", "metadata": {...}},
    {"id": "i-2", "addr": "10.0.1.46:8080", "health": "alive"},
    {"id": "i-3", "addr": "10.0.1.47:8080", "health": "down"},
  ],
  "auth": [...],
  ...
}

Operations:

• Register: an instance announces "I'm a billing service at 10.0.1.45"
• Deregister: graceful shutdown
• Lookup: query "what billing instances are alive?"
• Health updates: status changes

Storage:

• Consensus-backed (Consul, etcd): consistent, durable, but limited write throughput
• Eventually consistent (Eureka): faster but stale data
• In-memory (Kubernetes endpoints): backed by etcd but cached aggressively

Each has trade-offs. Consul: 3-5 server nodes running Raft; agents on every host gossip. Eureka: peer-to-peer registries; AP not CP per CAP theorem.

The registry is the foundation. Everything else (load balancing, health checks, metadata routing) builds on top.