Service Discovery: Eureka, Consul — or Neither

The Problem, Stated Honestly

Two services need to talk. The naive answer is configuration:

inventory:
  base-url: https://inventory.internal:8080

Which is fine — genuinely fine — for a long time. It breaks when instances are dynamic: autoscaling changes their count, deployments replace them, and a crashed pod comes back with a different IP. A fixed hostname cannot name a set that changes every few minutes.

Service discovery replaces the address with a name, resolved at call time to whatever instances currently exist.

Read This Before Adopting Eureka

The roadmap covers Eureka and Consul, and they're worth understanding. But the honest guidance first:

That said, understanding registries is still worth it — the failure modes recur in any discovery mechanism, Kubernetes included.

Eureka

A dedicated server:

@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(DiscoveryServerApplication.class, args);
    }
}

server:
  port: 8761
eureka:
  client:
    register-with-eureka: false     # the server doesn't register with itself
    fetch-registry: false

And each service as a client:

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}

ext {
    set('springCloudVersion', '2025.0.0')
}
 
dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
    }
}

spring:
  application:
    name: inventory              # the name others will use — required
eureka:
  client:
    service-url:
      defaultZone: http://discovery:8761/eureka/
  instance:
    prefer-ip-address: true
    lease-renewal-interval-in-seconds: 30
    lease-expiration-duration-in-seconds: 90

spring.application.name is the registered name. Get it wrong and callers can't find the service — and since it's also the name in your metrics and traces, it's worth setting carefully once.

The lifecycle: register on startup, heartbeat every 30 seconds, deregister on graceful shutdown. Miss heartbeats for 90 seconds and you're evicted.

Self-preservation mode

Eureka's most misunderstood feature, and a genuine design decision worth understanding.

If Eureka stops receiving the expected heartbeat volume, it assumes the network is partitioned rather than that every service died and stops evicting instances. You'll see:

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT.

This is Eureka choosing availability over consistency. In a partition it would rather serve stale data — possibly including dead instances — than wrongly empty the registry and halt the whole system.

That is usually the right call for discovery: a stale registry entry plus a circuit breaker degrades gracefully; an empty registry stops everything. Disabling self-preservation is common in development, where few heartbeats make it trigger spuriously, and rarely right in production:

eureka:
  server:
    enable-self-preservation: false     # development only

Consul

HashiCorp Consul offers discovery plus active health checking and a KV store:

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-consul-discovery'
}

spring:
  cloud:
    consul:
      host: consul
      port: 8500
      discovery:
        health-check-path: /actuator/health/readiness
        health-check-interval: 10s

The important difference: Consul polls your health endpoint rather than waiting for heartbeats. Detection is faster and reflects whether the service is actually able to serve, not merely that its process is running — which is why pointing it at /actuator/health/readiness rather than plain /health matters, per the liveness/readiness distinction.

Consul's Raft consensus means it prefers consistency: a quorum loss makes it unavailable for writes. Eureka prefers availability. Neither is wrong — they're different answers to the partition question.

Using Discovered Services

@Bean
@LoadBalanced
RestClient.Builder loadBalancedRestClientBuilder() {
    return RestClient.builder();
}

@Service
public class InventoryService {
 
    private final RestClient client;
 
    public InventoryService(@LoadBalanced RestClient.Builder builder) {
        this.client = builder.baseUrl("http://inventory").build();   // the service NAME
    }
 
    public StockLevel stockFor(String sku) {
        return client.get().uri("/stock/{sku}", sku).retrieve().body(StockLevel.class);
    }
}

http://inventory is not a hostname — @LoadBalanced intercepts the call, resolves the name against the registry, and picks an instance. Guide 3 covers that selection.

Or query the registry directly, when you need the instance list:

@Service
public class InventoryTopology {
 
    private final DiscoveryClient discovery;
 
    public List<String> instanceUris() {
        return discovery.getInstances("inventory").stream()
                .map(i -> i.getUri().toString())
                .toList();
    }
}

When You Don't Need Any of This

Worth stating directly, because Spring Cloud is often adopted before the problem exists:

• One service. Nothing to discover.
• A handful of services with stable addresses. Configuration is simpler and has fewer failure modes.
• On Kubernetes. Service DNS already does this.
• Behind a load balancer per service. A single stable name already fronts the instances.

Service discovery addresses dynamic instance sets without platform support. If that's not your situation, it's infrastructure you operate for no gain — and a registry you have to keep available.

The Mental Model, Restated

1. Discovery replaces addresses with names, resolved at call time.
2. On Kubernetes you likely already have it. Two registries is worse than one.
3. spring.application.name is the registered name — also your metrics and trace identity.
4. Eureka is heartbeat-based with slow eviction — a dead instance can take ~2 minutes to disappear.
5. Self-preservation chooses availability over consistency in a partition. Usually correct.
6. Consul actively polls health, so point it at readiness, not liveness.
7. Discovery needs resilience alongside it — timeouts, retries, circuit breakers.
8. The registry is critical infrastructure. Replicate it; make clients cache.

What's Next

With services able to find each other, the next question is how traffic from outside enters the system. The next guide covers Spring Cloud Gateway: routing by predicate, filters for cross-cutting concerns, rate limiting with Redis, and which responsibilities belong at the edge rather than in every service.