Understanding Eureka’s Three‑Level Cache and Reducing Service Deregistration Delay

The author shares a real‑world Eureka (service registry) case where numerous alerts were triggered because services took too long to go offline, leading to request errors.

Eureka follows an AP model and uses a three‑level cache: the Registry stores instance data, which is immediately synced to readWriteCacheMap; this map updates readOnlyCacheMap every 30 seconds, and client applications (and Ribbon) read from the read‑only cache, also refreshing every 30 seconds.

Because the heartbeat interval is 30 seconds, a normal service shutdown can take up to 30 + 30 + 30 + 30 = 120 seconds to be perceived, while an abnormal shutdown may require three 60‑second eviction cycles, totaling about 300 seconds (5 minutes) in the worst case.

The console shows immediate registry data, which can be misleading; the actual client perception depends on the cache synchronization timings.

To solve the delay, the article suggests reducing the synchronization intervals and heartbeat settings, for example:

ribbon.ServerListRefreshInterval = 3000

eureka.client.registry-fetch-interval-seconds = 3

eureka.instance.lease-renewal-interval-in-seconds = 3

eureka.instance.lease-expiration-duration-in-seconds = 9

eureka.server.eviction-interval-timer-in-ms = 5000

eureka.server.response-cache-update-interval-ms = 3000

It also notes that the read‑only cache can be disabled with eureka.server.use-read-only-response-cache = false, though this is not recommended for typical use because Eureka is designed as an AP system and Spring Cloud Eureka always reads from the read‑only cache.

After applying the new timings, the maximum perceived shutdown time drops to 12 seconds for normal shutdowns and 27 seconds for abnormal ones.

The article concludes with references to additional Spring Cloud architecture resources and a promotional note for further learning materials.