The Service Discovery pattern lets services find the current network location of other services automatically, which is essential because microservices frequently change addresses as they scale up, scale down, or restart.
Key Points: • A service registry keeps a live list of available service instances and their network locations, updated as instances start, stop, or change. • Services (or a load balancer) query the registry at request time instead of relying on a hardcoded, static address that could quickly become stale. • This supports elastic scaling, since new instances become discoverable automatically and unhealthy instances are removed without manual configuration changes. • It removes the need for manual coordination when deploying or scaling services, since the registry reflects the system's real-time state. • Tools like Eureka, Consul, or Kubernetes' built-in DNS-based discovery implement this pattern in practice.
Example: When a Payment service scales from two instances to five during a sales event, Service Discovery automatically makes all five available to callers without anyone updating a configuration file, and when it scales back down, the removed instances stop receiving traffic just as automatically.
Interview Tip: A concise interview answer is:
"Service Discovery keeps a live directory of where each service instance actually is, since that location changes constantly as services scale and restart. It lets callers or load balancers look up healthy instances dynamically instead of relying on hardcoded addresses, which is what makes elastic scaling in microservices actually work."