When horizontally scaled (e.g. multiple containers running the server), the in-memory cache (which isn't distributed) might be stale. This is fine; cache will be eventually consistent after 5 minutes and clients will get any missing key data next time they make a request.
However, currently when we've stored a key set in the database, we append the new keys to the in-memory cache of the container handling the request. Because between the 5 minute cache refresh interval other containers might have handled uploads as well, there's the risk of a data gap in the cache, and the client won't notice this, especially if they'll use cursor based pagination.
To solve this for the in-memory cache implementation, we should simply not append to the in-memory cache. Cache will remain stale for a maximum of 5 minutes which is fine (see first paragraph), after which it will be set afresh from data from the repository (which is strongly consistent).
When horizontally scaled (e.g. multiple containers running the server), the in-memory cache (which isn't distributed) might be stale. This is fine; cache will be eventually consistent after 5 minutes and clients will get any missing key data next time they make a request.
However, currently when we've stored a key set in the database, we append the new keys to the in-memory cache of the container handling the request. Because between the 5 minute cache refresh interval other containers might have handled uploads as well, there's the risk of a data gap in the cache, and the client won't notice this, especially if they'll use cursor based pagination.
To solve this for the in-memory cache implementation, we should simply not append to the in-memory cache. Cache will remain stale for a maximum of 5 minutes which is fine (see first paragraph), after which it will be set afresh from data from the repository (which is strongly consistent).