Response cache

The Eureka Server caches responses by default. The cache is invalidated every 30 seconds. It can be easily checked by calling the HTTP API endpoint /eureka/apps. If you call it just after the registration of the client application, you will figure out that it is still not returned in the response. Try again after 30 seconds, and you will see that the new instance appears. The response cache timeout may be overridden with the responseCacheUpdateIntervalMs property. Interestingly, there is no cache while displaying a list of registered instances using the Eureka dashboard. In contrast to the REST API, it bypasses the response cache:

eureka:
 server:
   responseCacheUpdateIntervalMs: 3000

We should remember that the Eureka registry is also cached on the client side. So, even if we changed the cache timeout on the server, it may still take some time until it would be refreshed by the client. The registry is periodically refreshed in an asynchronous, background task that is scheduled every 30 seconds by default.  This setting may be overridden by declaring the registryFetchIntervalSeconds property. It only fetches the delta in comparison to the last fetch attempt. This option may be disabled using the shouldDisableDelta property. I defined 3 seconds timeouts on both the server and client sides. If you start the sample application with such settings, /eureka/apps will show the newly registered instance of the service, probably at your first attempt. Unless caching on the client side makes sense, I'm not sure about the sense of caching on the server side, especially since Eureka doesn't have any backend store. Personally, I have never had any need to change the values of those properties, but I guess it can be important, for example, if you develop unit tests with Eureka and you need an immediate response without caching:

eureka:
 client:
   registryFetchIntervalSeconds: 3
   shouldDisableDelta: true