Eureka vs Consul: Service Discovery Comparison

Direct Answer

Eureka is a Spring/Netflix-native AP service registry (availability over consistency) built specifically for service discovery. Consul is a broader infrastructure tool (CP with Raft consensus) providing service discovery, health checks, KV store, and service mesh — more operationally complex but better suited for multi-cloud or multi-language environments.

Code Example

The configuration surface for each registry highlights the philosophical difference.

Eureka — JVM-native, annotation-driven:

<!-- pom.xml: client -->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

@SpringBootApplication
@EnableDiscoveryClient  // Eureka auto-registers on startup
public class OrderServiceApp {
    public static void main(String[] args) { SpringApplication.run(OrderServiceApp.class, args); }
}

# application.yml (Eureka client)
spring:
  application.name: order-service
eureka:
  client:
    service-url.defaultZone: http://eureka-server:8761/eureka/
    registry-fetch-interval-seconds: 30
  instance:
    prefer-ip-address: true
    lease-renewal-interval-in-seconds: 30     # heartbeat every 30s
    lease-expiration-duration-in-seconds: 90  # evict after 90s silence
    metadata-map:
      version: '2.3.1'
      zone: us-east-1a

Eureka server (minimal):

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

# eureka-server application.yml
server.port: 8761
eureka:
  client:
    register-with-eureka: false
    fetch-registry: false
  server:
    enable-self-preservation: true            # classic AP behaviour
    renewal-percent-threshold: 0.85

Consul — same service, HTTP API + active probing:

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>

# application.yml (Consul client)
spring:
  application.name: order-service
  cloud:
    consul:
      host: consul.internal
      port: 8500
      discovery:
        register: true
        prefer-ip-address: true
        health-check-path: /actuator/health    # Consul actively probes this
        health-check-interval: 10s
        health-check-timeout: 3s
        health-check-critical-timeout: 30s     # deregister if critical this long
        tags:
          - version=2.3.1
          - zone=us-east-1a
          - secure=false
        instance-zone: us-east-1a

Raw Consul service definition (language-agnostic — a Go or Python service would register the same way):

{
  "service": {
    "name": "order-service",
    "address": "10.0.1.42",
    "port": 8080,
    "tags": ["version=2.3.1", "zone=us-east-1a"],
    "checks": [
      {
        "http": "http://10.0.1.42:8080/actuator/health",
        "interval": "10s",
        "timeout": "3s"
      },
      {
        "tcp": "10.0.1.42:8080",
        "interval": "30s"
      }
    ]
  }
}

The telling differences:

1. Registration mode — Eureka requires @EnableDiscoveryClient and classpath dependency (JVM-specific). Consul uses an HTTP API that any language can call — a Go service ships with consul.Client.Agent().ServiceRegister(...) identical in spirit to the YAML above.

2. Health checks — Eureka uses passive lease renewal (lease-renewal-interval-in-seconds: 30). A broken service that still heartbeats appears healthy. Consul actively probes health-check-path; a service returning 503 on /actuator/health is deregistered within health-check-interval + critical-timeout.

3. Multi-kind checks — Consul supports multiple simultaneous checks per service (HTTP + TCP above). A single failed HTTP check marks the service unhealthy even if TCP is up. Eureka's single-signal heartbeat can't express this.

4. CAP signal in config — enable-self-preservation: true in Eureka is the AP tell; Consul's requirement of a server quorum (configured in consul-server.hcl, not shown) is the CP tell.

Consul also gives you the KV store for free:

consul kv put features/new-checkout-ui true
consul kv get features/new-checkout-ui

Spring services read via spring-cloud-starter-consul-config. Eureka has no KV equivalent.

Common Mistakes & Pitfalls

Assuming Consul is always better because it's CP — for service discovery in a single-datacenter Spring-only environment, Eureka's simplicity and native Spring integration are often the right trade-off