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.
