Service Discovery & API Gateway
Netflix Eureka — Registering and Discovering Services
Eureka Server configuration, client heartbeats sync, and client-side load balancing (LoadBalancer).
Interview: Eureka architecture details. Expect questions on Eureka server clustering, self-preservation mode mechanics, registry caching loops, and heartbeat intervals tuning.
Introduction
When building microservices with Spring Cloud, you need a dynamic, high-availability registry to track healthy services. **Netflix Eureka** serves as the central directory registry where clients register their presence and retrieve active target lists.
Eureka operates in two parts: the **Eureka Server** (the central registry database) and the **Eureka Client** (applications that register themselves and query the server for other service locations).
Why It Matters
Eureka enables automatic registration of instances, monitors application health via heartbeats, and works with Spring Cloud LoadBalancer to provide client-side routing.
Self-Preservation Mode
During a network partition, Eureka Clients might lose connection to the Eureka Server but remain active and capable of serving traffic. By default, if the server detects client heartbeats falling below a threshold (typically 85% of expected renewals), it enters **Self-Preservation Mode**.
In Self-Preservation mode, Eureka stops evicting expired instances from its registry, protecting the system from deleting healthy instances during transient network drops.
Practical Example
Let's write the configuration file for a Eureka Client application:
Next, annotate your main Spring Boot class:
Quick Quiz
Q1: What triggers Eureka Server's "Self-Preservation Mode", and what action does the server take?
A) It is triggered by high memory usage, causing Eureka to delete inactive registry entries.
B) It is triggered when client heartbeat renewals drop below the expected threshold, causing the server to stop evicting expired instances to protect healthy nodes during network partitions.
C) It is triggered by database connection failures.
D) It is triggered by unauthorized API requests.
Answer: B — Self-Preservation prevents Eureka from cleaning out instances when heartbeats drop, protecting the registry from data loss during network disruptions.
Scenario-Based Challenge
Production Scenario:
In your staging environment, developers frequently restart and destroy container instances. Eureka enters self-preservation mode and retains terminated instances in the registry, causing clients to try to connect to dead IPs and fail. How do you resolve this behavior?
View Solution
To optimize Eureka for staging and testing environments:
1. **Disable Self-Preservation:** Turn off self-preservation on the Eureka Server:
eureka.server.enable-self-preservation=false
This ensures expired instances are evicted immediately.
2. **Accelerate Eviction Sweep:** Speed up the server's eviction sweep timer (in milliseconds):
eureka.server.eviction-interval-timer-in-ms=5000 (sweep every 5 seconds).
3. **Speed Up Client Heartbeats:** In staging clients, reduce the lease parameters to detect restarts faster:
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=30
Interview Questions
1. How do Eureka clients maintain registry information locally, and how does this affect system resilience?
Eureka clients fetch and cache the entire registry database locally, updating it periodically (defaults to every 30s). If the Eureka Server crashes or becomes unreachable, clients can still resolve and route traffic using their local cache, preventing total system downtime during registry failures.
Production Considerations
Secure your Eureka dashboard and API access in production. Use Spring Security to enforce basic authentication and ensure all clients use credential-embedded registry URLs.