Edge and reliability / Intermediate / 5 min
Service discovery: registry, heartbeats and stale caches
Instances heartbeat to a registry; clients cache the list. Crash one and see traffic hit it until TTL and caches expire.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- Service discovery keeps a live list of which instances of each service are up, from registrations and heartbeats, so clients know where to send requests.
- Why it matters
- Instances come and go with deploys, autoscaling and crashes, and hard-coded addresses break immediately.
- The trade-off
- Short TTLs and caches notice failures fast but cost registry load and risk flapping; long ones are cheap but route to dead instances.
- Say it in an interview
- "Instances register in Consul/etcd (or Kubernetes endpoints) with health checks, clients watch for changes or cache briefly, and retry another instance on failure."
Check yourself
An instance crashes. Why do some requests still go to it?
Answer: The registry waits for its TTL to pass, and clients keep using their cached list until they refresh. Worst case is roughly TTL plus the client cache time; client-side retries to another instance hide most of it.
What does a shorter registry TTL cost?
Answer: More frequent heartbeats, and more false removals during short network blips. Fast detection and stability pull in opposite directions; heartbeats every TTL/3 tolerate a missed beat or two.
Why can a new instance sit idle right after it starts?
Answer: Clients only learn about it when they next refresh their cached list. Discovery is eventually consistent; push-based watches (Consul, Kubernetes endpoints) shorten that gap.