1

I'm building a microservices architecture that should deal with:

  1. Direct database access
  2. Call to external legacy services

I can think about 2 caching strategies, but can't figure out what is the best considering that I will not have control on what other people could do across the layers.

Caching at application level (@Cacheable)

I only provide a caching feature that everyone can use, by enforcing the spring.cache.redis.key-prefix to the microservice name to limit conflicting keys.

  • PRO: most flexible way
  • CONS:
    • No control over cache except for maximum space: people would just create new cache entries
    • No control over cache invalidation: we don't know what kind of data is actually stored so if, for example, a legacy system needs to be reloaded we cannot empty some cache keys
    • Possible redundancy: as caching is at application layer it could happen that microservices store about the same data. While I could have control on the database (one MS should own its own db or at least a subset of tables) I can't guarantee about the legacy SOAP layer

Caching at service layer (connectors)

I don't provide a caching feature but I provide custom soap connectors that will/will not cache response based on a configuration that I will provide (could also be a blacklist/whitelist)

  • PROS:
    • cache is controlled
    • easy to invalidate
  • CONS:
    • need to update connectors each time a cache policy changes
    • dependency between development and architecture

edit: I need suggestion about the theoretical approach, not about a specific technology.

Phate
  • 6,066
  • 15
  • 73
  • 138
  • Does this answer your question? [Choosing a distributed shared memory solution](https://stackoverflow.com/questions/3045164/choosing-a-distributed-shared-memory-solution) – jaco0646 Mar 11 '20 at 23:29
  • Edited: in the link provided the solution is about using hazelcast as a technology. I'm looking at best practices/methods over the specific technical solution. – Phate Mar 12 '20 at 08:39

1 Answers1

1

I suppose you should build different microservices (apis) to deal with different set of responsibilities. Like , you can have a one microservice which deals with legacy and other one which deals with database. In order for these two microservices to communicate, you can have a message broker architecture like apache kafka (hazelcast being cost effective or Rabbit MQ). Communication between these two microservices can be event driven as well. Once you decide this, then you can finalize where to place your cache. You will need to place cache at application level and not service level if there is an UI where you are showing these values.

CovetousSlope
  • 171
  • 11