Eureka

## What Eureka actually is Netflix Eureka is a **service registry**: a small HTTP server whose entire job is to hold the answer to "which instances of which application are currently up, and at what address?". It is deliberately *not* a proxy or a load balancer. No request between two of your services ever passes through a Eureka server, which is why a Eureka outage is survivable in a way that a reverse-proxy outage is not. ## Step 1 — registration On startup, the instance's embedded Eureka client builds a record of itself: application name (the logical service, e.g. `ORDER-SERVICE`), a unique instance id, hostname and/or IP, port, an initial status such as `STARTING` or `UP`, a health-check URL, and arbitrary key/value metadata. It sends that record to the server, which stores it as a **lease**. The important property is that the instance describes itself. The server does not discover anything; it believes what it is told. A misconfigured instance that advertises a container-internal IP that nobody outside can route to will register perfectly happily, and callers will fail to reach it. ## Step 2 — renewal (the heartbeat) The client then renews its lease on a timer — `leaseRenewalIntervalInSeconds`, default **30 seconds**. Each renewal resets the lease clock, which is configured by `leaseExpirationDurationInSeconds`, default **90 seconds**. Miss enough heartbeats and the server's eviction task removes the entry. This is heartbeat-based (passive) liveness, and its limitation is worth saying out loud in an interview: a heartbeat proves the client's background thread is scheduled, not that the application can serve a request. A JVM with an exhausted request thread pool, a broken database connection, or a wedged downstream will keep heartbeating cheerfully while failing every real call. If you want a stronger signal, an instance can *report* a status change itself, and an operator can force one through the registry's REST API: ```bash curl -X PUT "$EUREKA/apps/ORDER-SERVICE/i-0abc123/status?value=OUT_OF_SERVICE" ``` That takes an instance out of rotation without killing the process — the standard way to drain one node. ## Step 3 — the caller fetches the registry A calling service does **not** ask the registry "where is order-service?" on each request. Its Eureka client downloads the *whole* registry once at startup and then refreshes on a timer — `registryFetchIntervalSeconds`, default **30 seconds**. Refreshes are normally *delta* fetches: the server returns only recent changes, and the client compares an application hash to detect drift, falling back to a full re-fetch when the two disagree. The result is kept entirely in the caller's memory. ## Step 4 — the caller chooses an instance Because the list lives in the caller, the caller also does the load balancing: it applies its own policy — round-robin, zone affinity, availability filtering — to the cached list and opens a connection straight to the chosen instance. This is what "client-side" means concretely in Eureka. ```bash # The registry is just a REST resource you can read yourself curl -s -H 'Accept: application/json' "$EUREKA/apps" | head -40 ``` ## What this design buys, and what it costs It buys **availability and cheapness**. There is no component in the data path to size, and if every Eureka server dies, running callers keep using their last cached list and keep serving traffic. Each caller can also make its own routing decisions — prefer its own zone, weight instances differently — which a shared load balancer cannot express per-caller. It costs **freshness and reach**. Every caller is up to a fetch interval behind the registry, which is itself up to a lease duration behind reality, so a dead instance stays in someone's list for a while. And the model only works for callers that embed a Eureka client, which in practice means JVM services: a non-JVM service or an external client cannot join without a translation layer. ## The one-line summary for an interview Register, heartbeat, fetch, choose. The instance keeps itself alive by heartbeat; the caller keeps a cached copy of the whole registry and load-balances locally; the registry is only ever consulted out-of-band, never in the request path.