> While an exception, this is a very real possibility in day to day
> operations. The absence of any feedback or balancing mechanism between
> the database and cache makes it impossible to know that they are in sync
> and even a small error percentage multiplied over time will lead to an
> ever increasing likelihood of error.
Sure, but there are applications where it does not matter, and these
applications are othen loading the database... think about displaying
forum posts, products list in a web store, and especially category trees,
top N queries... for all these, it does not matter if the data is a bit
stale. For instance, a very popular forum will be cached, which is very
important. In this case I think it is acceptable if a new post does not
appear instantly.
Of course, when inserting or updating data in the database, the primary
keys and other important data should be fetched from the database and not
the cache, which supposes a bit of application logic (for instance, in a
forum, the display page should query the cache, but the "post message"
page should query the database directly).
Memcache can also save the database from update-heavy tasks like user
session management. In that case sessions can be stored entirely in memory.
ON COMMIT triggers would be very useful.
> More dangerous is that this discrepancy will NOT always be apparent
> because without active verification of the correctness of the cache, we
> will not know about any errors unless the error grows to an obvious
> point.
> The errors may cause material damage long before they become obvious.
> This is a common failure pattern with caches.
This is why it would be dangerous to fetch referential integrity data
from the cache... this fits your "banking" example for instance.
