maybe this helps:
The Two Level cache mechanisms
The « two level cache » system allows to get a fast cache backend and
a slow cache backend. The main problem here is that only file and
database structures allow the slow backend to be really efficient
because a “home made” structuring of these content can be done.
With APC or Memcached, we can get a two way associative structure but
still very simple. Magento handles large data collections, with type,
category, groups, etc… A simple structure can’t really fulfill the
need of Magento’s cache. In order to be able to work properly, Magento
need a slow backend cache that could be structured properly and have
extended value/capabilities. In the fast_backend, we then only have a
key (element id) and the content of this key (the element that is
cached). It’s a bit like if you have a mailing system that store a
mail content with an ID and another DB that help structuring it with
folders and attributes. The “raw” data is stored in the fast_backend,
the intelligent mapping of these data is stored in the slow_backend.
This way, Magento can selectively delete or update a key or a category
without having to flush all the cache every time an update is made.
If you impose a “non configurable” slow cache backend to Magento, it
won’t be able to selectively clean the part of the cache that are
impacted by a manipulation, it then renders the whole caching
mechanism quite useless.