alt Hacker Newsthat was an interesting read (https://junchengyang.com/publication/nsdi24-SIEVE.pdf), thanks for the recommendation. It looks like a good fit for replacing the underlying storage mechanism of Pocache, instead of the LRU. Though I do not think it addresses the thundering herd problem, where the underlying database would be flooded with calls when the cache expires. I think Pocache is focusing more on the caching strategy itself rather than the cache eviction or storage mechanisms. Hence the store is configurable for Pocache.
SIEVE is merely eviction strategy.if you need to put cache above the database, that has little to do with the cache itself. thundering herd is again different thing altogether and can be easily mitigated by simple queue/custom logic. usually none of these things belong into cache but next to it. meaning, you "get" value and if there is no entry, you proceed to fetch it from wherever you need and set it. to avoid concurrent fetching, you synchronize your code with mutex or queue or whatever. all these things belong into your code, not the cache.