When would you choose Consul over Eureka for service discovery in a Spring Cloud system, and what architectural trade-offs are you accepting?

**Framing.** Both integrate with Spring Cloud through the `DiscoveryClient` abstraction, so application code (`@LoadBalanced` clients, `DiscoveryClient.getInstances`) is largely portable. The decision is about the **runtime platform and its consistency/operational model**, not app code. **What Consul brings.** - **Unified platform**: discovery + a Raft-backed **KV config store** (replaces/augments Spring Cloud Config Server) + rich **health checking** (HTTP/TCP/TTL/script) + optional service mesh (Connect) + ACLs. - **Strong consistency (CP)**: the catalog and KV are linearizable via Raft. Reads can be made consistent; you won't discover an instance the leader never committed. - **Multi-datacenter**: native WAN gossip federation; each DC has its own authoritative catalog. - **Language/tech agnostic**: HTTP + DNS interfaces, so non-JVM services and infra tools integrate the same way. **What Eureka brings.** - **AP design**: the registry prioritizes availability. Under partition, **self-preservation** stops evicting instances (assumes network, not instances, failed), so clients keep getting a (possibly stale) list and registration keeps working. Great when you'd rather route to a maybe-dead instance than fail registration. - **JVM/Netflix-native**, peer-replicated (no leader), client-side caching, very battle-tested for large JVM fleets. - **Simpler mental model** if you only need discovery; but you'll pair it with a separate config solution (Config Server) and it's effectively JVM-centric. **The CAP trade-off in practice.** - **Consul (CP)**: if a partition costs the server cluster its quorum, *writes* stall — new instances can't register, KV can't change — but the system won't serve divergent/split-brain state. Existing catalog entries and gossip-based liveness still work on the majority side. You accept possible write-unavailability to guarantee consistency. - **Eureka (AP)**: always accepts registrations and serves reads, at the cost of temporarily inconsistent/stale views across peers. You accept staleness to guarantee availability. **Other decision factors.** - **Operational cost**: Consul requires running and sizing a server quorum (odd 3/5), managing gossip ports (UDP), and ACL/encryption for secure KV. Eureka is a simpler pair of replicated servers but with weaker consistency guarantees. - **Config needs**: if you want one tool for discovery *and* dynamic config with live refresh, Consul consolidates; with Eureka you add Config Server (or Consul/Vault anyway). - **Health semantics**: Consul's server-side health checks are richer than Eureka's client-heartbeat renewal model. - **Kubernetes**: if you're on K8s, native K8s discovery or a mesh may beat both — Consul still adds value for cross-cluster/multi-DC or KV/mesh. **Gotchas / senior nuances.** - Don't overstate Consul unavailability: only *writes* block on quorum loss; discovery *reads* of existing services and gossip liveness continue on the healthy majority. - Eureka self-preservation can mask real outages (stale instances linger) — you trade false positives for availability. - Migrating between them is low-risk at the code layer (DiscoveryClient) but high-effort at the ops/consistency-assumption layer. **When to choose which (summary).** Consul: you want consolidated discovery+config+health, strong consistency, multi-DC, or polyglot/mesh. Eureka: JVM-only fleet, discovery-only, and registration availability under partition trumps consistency. Neither: managed platform (K8s/service mesh) already gives you discovery natively.