Distributed Cache Across Microservice Domains

Question

Is managing @CachePut in a different microservice from @Cacheable in a distributed cache environment an anti-pattern?

I'm working on spring boot microservices that are split across two domain categories: data ingestion and UI. The ingestion is separated from the UI services so that bursts of data will not impact response times. Once the data is ingested, we fan it out on kafka to a persistence service for storage and a session service for real-time determinations such as user notifications.

To ensure that I can keep up with the ingestion rate, I want to cache the user notification configuration in my ingestion pipeline after the initial REST lookup. But if a user updates their configuration in the UI (eg increase / decrease warning threshold, turn off warnings, change to digest), I want the cache refreshed with that update. Because I will be auto-scaling these services to meet demand, I plan to use distributed cache.

Does splitting @CachePut and @Cacheable across two different microservices in a distributed cache configuration constitute an anti-pattern? Would sending the objects across kafka constitute a better alternative?

My gut tells me to avoid splitting the cache management across microservices like this because I can imagine someone changing the cache keys in one service and forgetting to change them in the second. On the other hand, sending them across kafka to a consumer in the session service would look ugly, something like this:

@CachePut(value = "config", key = "new SimpleKey(#config.userId, #config.applicationId)")
public UserApplicationConfig fakeSave(UserApplicationConfig config) {
  // not actually saving anything, just need somewhere to put my CachePut annotation
  return config;
}

Answer 1

@CachePut always lets the method execute. It is generally used if you want your cache to be updated with the result of the method execution. Example: When you want to update a stale data which is cached, instead of blowing the cache completely.

@Cacheable will be executed only once for the given cachekey and subsequent requests won't execute the method, until the cache expires or gets flushed.

This is based upon your design decision. Its not an anti pattern. Spring Data JPA also uses interface repositories with Annotations, this does not mean, there is no need to create the "Fake" interface even.

Its a way to capture the annotation (Annotation Processing).

Answer 2

Of course it is an anti pattern since it breaks the service boundaries, data hiding in particular.

When the user data is updated, you want to update the service clients that have a cached version of your user data. A better design would send an event "User data changes" and let service clients subscribe to it.

With a distributed cache you introduce possible points of failure, latency and configuration options for consistency, which are not simple.