A service registry is the central directory microservices use to locate each other, so its failure can disrupt service-to-service communication across the entire system.
Key Points: • Services that need to look up a new location (for example, after scaling or a restart) would be unable to find healthy instances of the services they depend on. • Existing cached instance lists on the client side (many discovery clients cache the last known registry state) may allow communication to continue temporarily, but that cache will go stale. • New service instances would be unable to register themselves, so they'd remain effectively invisible and unreachable to the rest of the system. • This makes the registry a critical single point of failure unless it's deployed redundantly — most production setups run a registry cluster (e.g., a multi-node Eureka or Consul cluster) rather than a single instance. • Health checks and failover between registry nodes reduce the risk, along with client-side caching that provides a grace period during a brief registry outage.
Example: If a single-node Eureka server crashes, services with a cached registry snapshot might keep working for a while, but any new instance that starts up during the outage won't be able to register, and lookups for services that scaled or moved will start failing.
Interview Tip: A concise interview answer is:
"If the registry goes down, services lose the ability to discover new or updated instance locations, which can break communication across the system, though client-side caching often provides a short grace period. That's why in production the registry itself should run as a highly available cluster rather than a single instance, so this failure mode is unlikely in practice."