Understanding Eureka Registration Center: Client Registry Fetching and Server Cache Mechanism

Hello everyone, I am Wukong. This is the fifth article in the series on the Eureka registration center, summarizing the client’s initial registry fetch and the server’s cache handling.

1. Introduction

The registry is essential for a service discovery system because all functionality revolves around it. For example, Service A needs Service B’s IP address and port to communicate.

Traditionally, once Service A knows Service B’s address, it sends an HTTP request directly to Service B’s API endpoint.

In a service discovery setup, the address information of Service A and Service B is stored in the registration center’s registry, which centrally manages registration and deregistration. Both services query the registry to obtain the full registry, thereby learning each other’s IP and port.

In the previous article, we mentioned that after a Eureka client successfully registers with the Eureka server, the server stores the registry information in a ConcurrentHashMap .

How does a client obtain other clients’ registration information?

2. First Retrieval of Registry Information

When Service B registers with the registry, Service A (the Eureka client) initially has no local registry data, so it pulls the entire registry from the server.

For the registration center, Service A is a "first‑time visitor" and wants to store all registration information locally for convenient API calls.

From the source code, the client fetches the full registry during DiscoveryClient initialization.

Client Sends Fetch Request

During initialization, the client checks whether it should fetch the registry:

if (clientConfig.shouldFetchRegistry() && !fetchRegistry(false)) {
    fetchRegistryFromBackup();
}

The logic means that if shouldFetchRegistry is enabled, the client invokes fetchRegistry to obtain the registry.

Because this is a new client, its local applications variable is null . The client evaluates three conditions; the second condition (registry is empty) triggers a full fetch.

Condition 1: Forced full fetch – not set (false).

Condition 2: Registry is empty – applications == null , so full fetch is required.

Condition 3: Number of registered clients equals 0 – also true, leading to a full fetch.

Therefore, the client calls getAndStoreFullRegistry() , which sends an HTTP request to the server’s getApplications() endpoint.

getApplications()

The server handles this request in the ApplicationsResource class’s getContainers method, which retrieves the server‑side registry.

3. Server‑Side Registry Cache

The server caches the registry in two levels: a read‑only cache ( readOnlyCacheMap ) and a read‑write cache ( readWriteCacheMap ).

Cache retrieval logic:

Jersey servlet receives the HTTP request.

It first looks in the read‑only cache.

If not found, it checks the read‑write cache.

When found, it updates the read‑only cache and returns the data.

If still not found, it returns null.

Open questions (to be covered in a later article on cache architecture):

(1) How is the two‑level cache populated? (2) How is cache data updated? (3) How does cache expiration work?

After the client obtains the registry, it stores it in the local variable localRegionApps for subsequent use.

localRegionApps.set(this.filterAndShuffle(apps));

4. Summary

The registry is vital for both client and server:

Server side uses multi‑level caching to serve registry queries efficiently.

Client side performs a full registry fetch on first startup and keeps a local copy.

Next time: how does the client fetch the registry on subsequent interactions?

- END -