# Lu Pan - Cache Made Consistent (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/62072237) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Lu Pan]] **Full Title**:: Cache Made Consistent **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #work **URL**:: [engineering.fb.com](https://engineering.fb.com/2022/06/08/core-infra/cache-made-consistent/) **Host**:: [[engineering.fb.com]] **Highlighted**:: [[2026-07-16]] **Created**:: [[2026-07-18]] ## Highlights - There are different ways to solve this problem, one of which involves maintaining a version field. This allows us to perform conflict resolution, as older data should never overwrite newer data. But what if the cache entry “x=43 @version=2” gets evicted from cache before “x=42” arrives? In that case, the cache host would lose knowledge of the newer data. ([View Highlight](https://read.readwise.io/read/01kxmt9mnkst9sy0099mk8c1m4)) ^1034628591 Version makes the problem less pain, but cannot fix it. - Data in cache is not durable, which means that sometimes version information that is important for conflict resolution can get evicted. ([View Highlight](https://read.readwise.io/read/01kxmwkw0pnafe163wdkaf59ca)) ^1034631795 - If we focus on the cache host timeline at the bottom, we see that after a client write, there’s a window in which both the invalidation and the cache fill can race to update the cache. After a while, the cache will be in a quiescent state. Cache fills can still happen in high volume in this state, but from a consistency perspective, it holds less interest, given there are no writes and it’s reduced to a static cache. ([View Highlight](https://read.readwise.io/read/01kxmxck3y78m9n3h525sd92zp)) ^1034633161