> 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 updat

> 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.