Your JVM services discover each other through Eureka today, and the platform is moving onto an orchestrator that already tracks which instances of each service are ready. How would you decide whether Eureka stays?

## Reframe the question before answering it An interviewer is not asking whether Eureka is good. They are asking whether you can recognise that **a capability moved into the platform**, and whether you can retire something that still works. The frame is: what does Eureka know that the platform does not, and is that knowledge worth a second registry? ## What changes underneath you On a VM fleet, Eureka was the only thing that knew where instances lived, and self-registration was the only mechanism available. Under an orchestrator, membership is already tracked as a first-class fact: the platform starts the instance, gates it behind a readiness signal, knows its address, and removes it from the routable set the instant it stops being ready or begins terminating. That is strictly more information than a heartbeat conveys, and it arrives strictly sooner. ## Three concrete frictions when both run **Two sources of truth with different eviction semantics.** The platform removes an instance on failed readiness in seconds. Eureka removes it on lease expiry plus an eviction sweep plus cache turnover, in minutes. Your callers route on the slower one, so the platform's fast, accurate removal buys you nothing at the point where it matters. **Self-preservation fights the orchestrator.** Rolling deploys and autoscaling produce exactly the pattern that trips self-preservation: many instances stopping in a short window. The registry then refuses to evict anything, including instances the platform has already terminated, precisely during the deploy when addresses are churning fastest. **Deregistration becomes a race with the termination grace period.** A pod receiving a stop signal must send its cancel to the registry and finish in-flight work before it is forcibly killed. Get that ordering or that grace window wrong and every rollout leaves a trail of leases pointing at addresses that no longer exist — and in a cluster, addresses get **reused**, so a stale entry can point at a completely different workload rather than at nothing. ## What Eureka still legitimately offers **Reach beyond one cluster.** A registry is just a list; it does not care where a member runs. If callers must find instances across two clusters, or in a cluster and on legacy VMs during a multi-year migration, a single registry spanning both is a real answer and the platform's in-cluster membership is not. **Per-caller routing policy.** Client-side discovery lets each caller apply its own selection — zone affinity, weighting, filtering on instance metadata your application defines. Flat platform routing typically expresses none of that. **Application-level metadata.** Eureka carries arbitrary key/value data about an instance — version, feature capability, region — that callers can filter on. If your routing logic genuinely reads that, moving it costs work. **Independence from cluster networking.** Callers hold addresses and connect directly, with no dependency on the platform's own resolution path being healthy. ## The decision, stated plainly - **Single cluster, no external callers, no per-caller policy → delete it.** Two registries is worse than either alone, and the one you would be keeping is the slower and less-informed of the two. Retire it; do not keep it "just in case", because a registry nobody trusts still gets consulted at 3am. - **Hybrid or multi-cluster reach, or real dependence on client-side policy → keep it, deliberately.** Then make the platform's readiness the authority on whether an instance is usable, keep the Eureka lease short, guarantee cancellation on shutdown inside the grace period, and be honest that during a partition self-preservation is going to serve stale addresses. - **Mid-migration → run both, with an end date.** Keep the registry authoritative only for the population that has not moved, migrate callers service by service, and treat "Eureka removed" as an explicit deliverable with an owner. The failure mode here is organisational, not technical: transitional infrastructure survives when nobody is accountable for deleting it. ## How you would know you were right Measure the window between an instance stopping and the last caller ceasing to dial it, before and after. If Eureka's removal is consistently the long pole, that number *is* the argument for retiring it — and if it is not, you have found a genuine reason it is still earning its place.