Microservices keep their registration and discovery information current by registering with a Service Registry on startup and continuously sending heartbeats to prove they're still alive.
Key Points: • When a service instance starts, it registers its network location and metadata with the registry, such as Eureka or Consul. • The instance sends periodic heartbeat signals to the registry to confirm it's still healthy and reachable. • If the registry stops receiving heartbeats from an instance within a configured timeout, it marks that instance as down and removes it from the list of available instances. • When an instance's location changes, such as during a redeploy, it re-registers with its new details so callers don't keep routing to a stale address. • This self-updating mechanism means the registry stays an accurate, near-real-time reflection of the system without requiring manual updates.
Example: When a Payment service pod is rescheduled to a new node in Kubernetes, it gets a new internal IP; Kubernetes' service discovery updates automatically, and if using Eureka instead, the new instance registers itself and starts sending heartbeats while the old instance's entry expires once its heartbeats stop.
Interview Tip: A concise interview answer is:
"Services register themselves with the registry on startup and keep sending heartbeats to prove they're still healthy. If heartbeats stop, the registry removes that instance so other services don't try to call something that's no longer there. That heartbeat-driven registration is what keeps service discovery accurate as instances scale, restart, or move."