These days I was asked by our technological leader to pollute a cache on purpose.

The exact nature of the request impacts a back-end (BE) system that operates on a database through a client library.

The BE is a Java Spring Boot application and the client library carries out its operations and internally maintains its Caffeine cache.
It can happen the system takes a few hundreds of milliseconds to answer client requests; partly due to the high complexity of carried-out checks and to a single instanced slow database, on which I can’t operate.

The request about polluting the cache has been justified as a strategy to avoid a set of requests to the BE system to prevent slowdowns the client library could suffer. The client library is in turn exploited by a third BE to provide service.

Here is a synthetic version of the schema: 3rd BE <=> library (cache here) <=> BE 1 <=> DB.

One important detail about BE 1 is that the DB is responsible for storing entities and generating keys, that are incremental integers. The strategy he suggested is to update the library and allow adding the entity to the cache, in such a way that when requests are made cache hits will prevent BE 1 from being queried.

To me, this request is absurd.
It presents problems on several fronts:

1. concurrency issues,
2. cache clearing problems,
3. lack of persistency,
4. high programming costs,
5. high maintenance costs.

One strategy to achieve this result is to query the database and identify the ID the entity should get when persisted, add the entity to the cache, and when persist it to the database.
When an entity is actually persisted I should check whether the ID has been already taken by another concurrent write and check they do not conflict. In case the ID has been taken by another entity I should clear and re-pollute the cache.

The question is, are there alternatives to this (anti-)pattern?