> 1. The cache tried to fill the metadata with version.
> 2. In the first round, the cache first filled the old metadata.
> 3. Next, a write transaction updated both the metadata table and the version table atomically.
> 4. In the second round, the cache filled the new version data.
Another way to look at this is that while the database can handle writes to the 2 tables atomically, the caching layer can't do a consistent read from the 2 tables, because it is either too expensive to do the 2 reads from within a database transaction, or too expensive to do a single read with join?
Our current system also suffers heavily from distributed inconsistency, mostly due to these "too expensive" constraints imposed by an ex-FB guy, even though our scale is nowhere near FB level. Yes I am bitter.