Service Discovery with Eureka in Spring Boot

The High-Availability Pivot: Client-Side vs. Server-Side In a distributed system, hardcoding IP addresses in a `bootstrap.yaml` is a fast track to a 3:00 AM incident. When your Kubernetes pods recycle or your AWS Auto Scaling Group terminates an instance, your downstream callers are left holding a stale socket. The fundamental choice in service discovery isn't just "which tool," but rather "where does the routing intelligence live?"

If you lean on a standard Load Balancer (ELB/ALB), you are doing Server-Side Discovery. The client hits a DNS name, the LB checks its target group, and forwards the packet. This is simple but introduces an extra hop and a single point of failure in the network path.

Eureka shifts this to Client-Side Discovery. The client (your Spring Boot microservice) downloads the entire registry. It knows every IP of every available peer. This eliminates the middle-man load balancer for internal traffic.

[ Client-Side (Eureka) ]          [ Server-Side (Standard LB) ]
      +----------+                      +----------+
      | ServiceA |                      | ServiceA |
      +----|-----+                      +----|-----+
           |                                 |
    [Local Cache]                     [ DNS / VIP ]
           |                                 |
    +------v------+                    +-----v-----+
    |  ServiceB   |                    | Load Bal. |
    +-------------+                    +-----v-----+
                                       |  ServiceB |
                                       +-----------+

Branch 1: The Traffic Density Decision Your first engineering fork depends on how many services you are running and how frequently they scale.

Path A: High Churn / Low Latency If you are running a fleet where instances spin up and down based on queue depth (SQS/RabbitMQ triggers), and you cannot afford the 50-100ms latency penalty of an extra proxy hop, Eureka is the choice. By keeping the registry local to the `DiscoveryClient`, your microservice makes sub-millisecond routing decisions using Ribbon or Spring Cloud LoadBalancer.

Path B: Static Topology / Polyglot Stack If your stack involves Go, Rust, and Node.js alongside Spring Boot, Eureka becomes a burden. While Eureka has a REST API, the "magic" is heavily baked into the Netflix/Spring Java ecosystem. For polyglot environments with stable IPs, skip Eureka and use Consul or native Kubernetes `Service` abstractions.

Branch 2: Consistency vs. Availability (The CAP Theorem Split) Eureka is an AP (Available/Partition-tolerant) system. It prioritizes keeping the registry alive over ensuring every node has the exact same view of the world at the exact same microsecond.

Path A: Financial Consistency Requirements If you are building a distributed lock manager or a system where routing to a "decommissioned" node causes a catastrophic state failure (e.g., dual-primary scenarios in a database), Eureka is dangerous. It relies on heartbeat timeouts (default 30s) and background task renewals. An instance can stay in the registry for nearly 90 seconds after it has actually died. In this case, use ZooKeeper or etcd (CP systems).

Path B: Resilient Microservices For 99% of web APIs, Availability is king. If the Eureka server loses its connection to the rest of the cluster, it enters "Self-Preservation Mode." It stops evicted services, even if they haven't sent heartbeats. This prevents a "mass extinction" event where a network glitch causes the registry to wipe itself out, leaving clients with no addresses to call.

Hardening the Registry: Server-Side Configuration To run a production-grade Eureka server, you must move beyond the `AlwaysIncludeEurekaServer` defaults. In a multi-zone AWS or GCP deployment, the registry must be peer-aware. If you run a single Eureka node, you have a single point of failure that brings down your entire service mesh.

In your src/main/resources/application.yaml:

```yaml
server:
  port: 8761

eureka: instance: hostname: eureka-node-1.internal.net client: registerWithEureka: true fetchRegistry: true serviceUrl: defaultZone: http://eureka-node-2.internal.net:8761/eureka/,http://eureka-node-3.internal.net:8761/eureka/ server: # Disable self-preservation in dev, but ALWAYS true in prod enable-self-preservation: true # How often to scan for expired leases eviction-interval-timer-in-ms: 30000 # Expected heartbeats (1 per 30s) renewal-percent-threshold: 0.85 ```

The renewal-percent-threshold is your "panic" button. If the server sees that fewer than 85% of heartbeats are arriving, it assumes there is a network partition, not a total service collapse, and it freezes the registry to protect the existing data.

The Client-Side Implementation: Registration and Discovery On the client side, we use `@EnableDiscoveryClient`. This is an abstraction; it doesn't care if it's Eureka, Consul, or ZooKeeper behind the scenes. However, the performance tuning is specific to Eureka's heartbeat mechanism.

```java
@SpringBootApplication
@EnableDiscoveryClient
@RestController
public class OrderServiceApplication {

@Autowired private RestClient.Builder restClientBuilder;

@GetMapping("/dispatch/{orderId}") public String processOrder(@PathVariable String orderId) { // "shipping-service" is the spring.application.name, not a DNS host return restClientBuilder.build() .get() .uri("http://shipping-service/ship/" + orderId) .retrieve() .body(String.class); } } ```

By using the service name shipping-service in the URI, Spring Cloud LoadBalancer intercepts the request. It looks into the locally cached Eureka registry, picks an instance (usually Round Robin), and replaces the hostname with a physical IP like 10.0.4.122:8080.

Tuning for Zero-Downtime Deployments The default Eureka settings are notoriously "lazy." If you do a rolling update of a service, it can take up to 90 seconds for the rest of the cluster to realize the old pods are gone. This leads to `ConnectException` or `503 Service Unavailable` errors during deployments.

I learned this the hard way in a cluster processing 15k requests/second. Our p99 latency spiked from 90ms to 4.2 seconds during a deployment because clients were still trying to hit dead IP addresses for 30 seconds after the pod was killed.

To fix this, you must tighten the lease intervals. This increases traffic to the Eureka server, but for a 100-node cluster, the overhead is negligible compared to the cost of failed requests.

Client Config for Fast Eviction: ``yaml eureka: instance: # Send heartbeats every 5 seconds instead of 30 lease-renewal-interval-in-seconds: 5 # Tell the server to kick us out if it hasn't heard from us in 10s lease-expiration-duration-in-seconds: 10 client: # Refresh the local cache every 10 seconds registry-fetch-interval-seconds: 10 ``

With these settings, the window of "stale routing" drops from ~90 seconds to under 15 seconds.

Branch 3: The Health Check Strategy How does Eureka know a service is "Up"? By default, it only cares if the service can send a heartbeat. If your service has a database connection failure but the JVM is still running, it will continue to send heartbeats, and Eureka will continue to route traffic to a broken node.

Path A: Basic Liveness (Default) If your service is stateless and has no external dependencies, the default heartbeat is sufficient.

Path B: Deep Health Checks If your service relies on a database (PostgreSQL/MongoDB) or a cache (Redis), you must link Eureka’s health status to Spring Boot Actuator.

Add the configuration: ``yaml eureka: client: healthcheck: enabled: true ``

When this is enabled, the EurekaHealthCheckHandler polls the Actuator /health endpoint. If the database goes down and Actuator reports DOWN, the heartbeat sent to Eureka will change from UP to OUT_OF_SERVICE. This allows the rest of the system to stop sending traffic to the unhealthy node automatically.

Managing the Registry Dashboard and Security The Eureka dashboard (accessible at the server's root URL) is a vital debugging tool, but it’s a security liability. In production, I’ve seen developers leave this wide open, exposing the internal IP addresses and metadata of the entire infrastructure.

Always wrap your Eureka server in spring-boot-starter-security. Use Basic Auth at a minimum, and ensure your clients use the credentials in their serviceUrl.

Security Configuration snippet: ``java @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf(csrf -> csrf.disable()) // Essential for Eureka clients to register .authorizeHttpRequests(auth -> auth.anyRequest().authenticated()) .httpBasic(withDefaults()); return http.build(); } } `` *Note: You must disable CSRF. Eureka clients do not use CSRF tokens for heartbeats, and if you leave it enabled, every heartbeat will return a 403 Forbidden, eventually causing the server to evict all instances.*

Handling the "Service Unavailable" Trap Even with tuned heartbeats, there is a period where a client might try to talk to a service that just died but hasn't been evicted. This is why Service Discovery alone is not enough. You must pair Eureka with a Resilience pattern (Circuit Breaker or Retries).

When using Spring Cloud LoadBalancer and Eureka, you should configure the Retry interceptor. If a request hits a stale IP from the Eureka cache and gets a Connection Refused, the client should immediately retry the request on a different instance from the registry.

spring:
  cloud:
    loadbalancer:
      retry:
        enabled: true
        retry-on-all-operations: true
        max-retries-on-next-service-instance: 2

This specific combination—tight Eureka heartbeats plus client-side retries—is what allowed our team to reduce production "deployment blips" from a 0.5% error rate to zero.

The Sharp Takeaway Eureka is not a set-it-and-forget-it tool. If you use the out-of-the-box settings, you are accepting a 90-second window of potential stale routing and ignoring the health of your downstream dependencies.

For high-scale Spring Boot environments, the recommendation is clear: Use Eureka when you need lowest-latency routing and can tolerate eventual consistency. Tune your lease-renewal-interval to 5 seconds, enable Actuator-driven health checks, and always implement client-side retries to bridge the gap between an instance dying and the registry updating. This turns Eureka from a simple "phone book" into a robust, reactive traffic management layer.