What is Service Discovery

In the basic level, order-service called product-service at http://localhost:8081. That works on a laptop. In production it breaks quickly:

• You run 3 copies of product-service to handle sale-day traffic. Which URL do you call?
• Containers get new IP addresses every time they restart.
• An instance crashes. Callers keep sending requests to a dead address.
• You scale up from 3 to 10 instances. Every caller needs a config change and a restart.

Service discovery fixes this. Every instance registers itself in a service registry under a logical name such as product-service. Callers ask the registry "where is product-service?" and get the list of live instances.

(1) register + heartbeat every 30s
 product-service #1 :8081 ----------------------+
 product-service #2 :9081 ----------------------+-->  +-------------------+
 order-service      :8082 ----------------------+     |  Eureka Server    |
                                                      |  :8761 (registry) |
                    (2) "give me product-service"     +-------------------+
 order-service  <------------------------------------------ [#1, #2]
       |
       | (3) pick one instance (load balancer, client side)
       v
 product-service #2 :9081   GET /api/products/7

If you deploy on Kubernetes, it already gives every service a stable DNS name (http://product-service:8081) and load-balances between pods. Many teams then skip Eureka. Eureka is still common on VMs, on-premise servers and older Spring Cloud systems, and it is asked about in almost every Spring microservices interview.