You have done a good job explaining how Memcached can be used to enhance performance of web applications.

Here are some articles that explain how [NCache](http://www.alachisoft.com/n... can do the same in a better and easier way.
>[Scalable WCF Applications Using Distributed Caching](http://www.alachisoft.com/r...

>[Scale ASP.NET Apps Through Distributed Caching](http://visualstudiomagazine...

>[Scaling Java and JSP Apps with Distributed Caching](http://java.sys-con.com/nod...

At the beginning we used to cache HTML output of fragments, boxes, columns, even whole pages. But we learned it is a nightmare to maintain if you roll out builds several times a week, and some servers still serve stale cached versions of HTML incompatible with cached versions of js, cached versions of css, cached versions of graphics, or simply cached versions of other parts of the site.

It took a lot of effort to drop this idea and replace all of its occurrences with caching the data (not the view).

From the time perspective I think it might have been solved in a different ways, here are some of them:
1. using "generational" keys -- keys that have a version tackled to their name. Each release could increment the version, rendering all old keys invalid
2. using separate network of memcaches just for HTML, and flush them after each release.
3. manually changing names of keys of HTML parts affected by the new release (actually we tried to do so for a year, but we failed)

One more problem with HTML cache is that it hides other bottlenecks in middleware and backend (actually it is also its main advantage!), which can hurt you when you invalidate the cache. This is true for all three solutions above, so you have to perform updates at 6 A.M...

First of all, I should introduce qbolec (as he used to call himself) to the broader audience. He is a software architect at nk.pl (former nasza-klasa.pl), the biggest social Polish website and the biggest Polish website at all. We've been working together for a few months and I've got to tell you that if you're looking for someone who knows how to build huge-traffic web applications, then he's the guy. Not to mention he was a member of the successful TopCoder competition team.

But enough of this buttering up :-). I'm afraid that - when it comes to a reasonable amount of traffic - qbolec is right about problems related to view cache. Warming that kind of cache up may be complicated and might lead to unnecessary calculations. Which cache keys should be filled up in the first place?

To be honest, the only type of cache I've been working with that seemed to be almost completely transparent, was the cache handled entirely by a library. Of course, it puts some limitations on how the data can be accessed. In this case, you should forget about complex JOINS or other complicated SQL features. Wrapping all such cases by a library may be too complicated or even impossible.

Another thing I think of is a data store that ensures reads and writes fast enough, so that the difference between them and memcached is insignificant. Maybe the key-value stores are the bright future of web applications? Time will show.