The general gist of it is that you store HTML snippets (e.g. a todo, a list containing, or a project containing lists) in some quick storage medium (in this case Memcached). Each snippet is stored under and accessed by a key that uniquely identifies the version saved (object type + ID + update timestamp). When a new version is cached, the old version stays in the cache, unused, until it is eventially dropped out by Memcached.
Now all you need to do is to ensure that whenever an object or its children change, you update their timestamp (the "touch" part), and if you make a changes to the code, you increment the version key for said cache piece. This way new requests will not hit old cached content.
Ok, so the first interesting part is that instead of caching the result of a database request we cache the complete rendered result. And the bigger rendered parts are just constructed by combining the smaller (also cached) parts, right?
How does the application learn which version an element is at right now? Don't you have to call the database to find out?
If you're rendering an object, you've likely already fetched it from the DB. Rails models (by default) will have a created_at and updated_at datetime columns that are automatically set and updated for you, and you can use them for exactly what is shown in the article.
Correct on all accounts. You will still need to query the database at least for the parent object being rendered. The time saved is shaved off from the rendering time.
when you cache some html wich depends on $some_object, use a key that includes that object "version" (e.g. a timestamp).
Then on first access you save the html for a key "object-x-v1" and on subsequent access you get the same html.
When the object changes (v=2), so will the key ("object-x-v2), and when you access the same content again you will have a cache miss and the html will be regenerated, while the stale cache will just stay in memory until it's naturally evicted from memcache.
(Links are fine, of course)