# Lu Pan - Cache Made Consistent (Highlights)  ## 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