What is a well documented caching strategy pattern for a microservice architecture dealing with legacy?

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