Simple. Most of the database is "large" in terms of data (say 50M rows) but that database gets maybe 10,000 updates a day. The read load is well-controlled with caching.
One table is small in terms of data but involves an interactive service that might generate 50 updates/sec at peak times.
With the "hot" service implemented on top of a key-value store, the database is the ultimate commodity, I have many choices such as in-memory with logging, off-heap storage, distributed key-value stores, etc.
The service is not "in front" of MySQL, but is on the side of it so far as the app is concerned.
