Why was the service discovery pattern needed in the first place? Consider the problems faced in a typical microservices setup:

• Dynamic Infrastructure: In modern deployments (virtual machines, containers, Kubernetes, etc.), services don't have fixed IPs or hosts. Instances come and go, scale up and down, and get replaced during deployments. For example, an auto-scaling group in AWS might launch new instances of a service or terminate them based on load, each time with new IP addresses. Keeping track of these moving targets is challenging.

• Undetermined Number of Instances: There could be multiple instances of the same service running for load balancing. Which instance should a client call? Hard-coding one address would not distribute load, and maintaining a list manually would be error-prone. As the number of services and instances grows, manual configuration becomes untenable.

• Decoupling: One goal of microservices is to allow teams to deploy and scale services independently. But if every client must know the exact address of every service, it creates tight coupling. A change in service location would mean updating configurations in every client that calls it. This tightly couples deployment details with the client’s configuration, reducing agility.

These challenges mean that a more dynamic and automated mechanism was needed to allow services to discover each other without prior knowledge of concrete network locations.