Service Discovery: Eureka & Client-Side Load Balancing
A service instance's IP address changes every time Kubernetes reschedules it. This module is how one service finds another without ever hardcoding where it lives.
Learning objectives
- Beginner: Register a service with a Eureka server and confirm it appears in Eureka's dashboard.
- Intermediate: Call another service by its logical name instead of a hardcoded host:port.
- Advanced: Explain how client-side load balancing distributes calls across multiple healthy instances without a centralized load balancer in the path.
◆ The problem
http://order-service:8080 might be correct today and wrong five minutes from now — a container restart, an autoscaling event, or a Kubernetes rescheduling gives that service a brand new address, and every other service with that URL hardcoded is now calling a dead endpoint.
A service registry solves this by having every service instance announce itself on startup ("I am order-service, reachable at 10.0.4.12:8080") and de-register on shutdown, so callers always ask the registry for a CURRENT address instead of remembering a stale one.
# eureka-server's application.yml server: port: 8761 eureka: client: register-with-eureka: false fetch-registry: false
@SpringBootApplication @EnableEurekaServer public class EurekaServerApplication { ... }
Any other service adds @EnableEurekaClient and a matching eureka.client.service-url.defaultZone property — on startup it registers itself, and Eureka's dashboard (at /) shows every currently-registered instance in real time.
▲ Worth knowing
Netflix put Eureka into maintenance mode years ago — it still works, is still fully supported by the Spring Cloud team, and is still genuinely the simplest way to learn service discovery's core ideas (which is why it's used here). But for a new production system today, it's worth knowing the field has moved: Kubernetes-native discovery (if you're already on K8s, Chapter 15's platform gives you this for free, no separate registry needed) or HashiCorp Consul are now more common real-world defaults than standing up a dedicated Eureka cluster.
Once order-service knows there are THREE healthy instances of inventory-service registered, calling one of them by logical name (http://inventory-service/api/stock) triggers Spring Cloud LoadBalancer to pick one instance itself, on the calling side — no traffic-routing hardware or centralized load balancer sits in between.
◆ Under the hood
This is the opposite of a traditional hardware load balancer, where every request funnels through one central device. Client-side load balancing spreads that decision-making across every calling service instead, removing a potential single point of failure and an extra network hop per call — the trade-off is that each caller needs its own up-to-date view of which instances are currently healthy, which is exactly what the registry provides.
A registered instance sends a heartbeat to Eureka every 30 seconds by default; missing several heartbeats in a row gets it evicted from the registry, so callers stop being routed to an instance that's crashed or become unreachable.
▲ Pitfall
Eureka's default eviction timing (roughly 90 seconds of missed heartbeats before removal) means a crashed instance can still receive a small number of calls for up to that long — a real availability gap that combining service discovery with the Circuit Breaker pattern (a later chapter) closes, by having the CALLER itself stop trying a consistently-failing instance faster than Eureka evicts it.
✓ Quick recap
- Hardcoded service URLs break the moment an instance is rescheduled — a registry always reflects current, live addresses.
- Eureka services register on startup and de-register on shutdown; @EnableEurekaServer/@EnableEurekaClient wire this up.
- Client-side load balancing picks a healthy instance on the CALLING side, with no centralized load balancer in the request path.
- Heartbeat-based eviction has a real lag — Circuit Breakers close the remaining gap.
Want a visual for this concept?
Generate a diagram tailored to “Service Discovery: Eureka & Client-Side Load Balancing” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →