A core issue for modern websites is one of cache invalidation. The linked article essentially sidesteps the issue, with the in-memory speed of memcache obscuring the problem.

For traditional LAMP-style document-producing engines, cache invalidation strategies rely either on TTL (leading, as he says, to stale data) or on polling the source data (leading to an unavoidable performance hit, amortised over the improved speed of the cache).

Leaving aside TTLs, the key issue is that cache invalidation is driven by GET and not POST requests. I wrote a thesis proposal where part of the concept was to drive all cache invalidation from POSTs. New comment added to a story? A regeneration is queued up. New post on front page? A regeneration is queued up.

Firstly, you can improve both staleness by only regenerating when new data is added, and you improve performance by not needing to poll the source data for currency every time you touch the cache. In an ideal situation you could come close to raw HTTP serving speed.

You also allow some degree of dynamic responses to load. Under high rates of POSTs you can batch up regeneration events to prioritise the GETs.

However, I won't be pursuing that project -- I've been accepted for one I was more interested in.