I've always been curious why someone hasn't (or why I haven't heard of someone) prototyping an improvement to MySQL's query cache to invalidate the cache less frequently and get more dependable usage. Currently it invalidates when any table referenced by the query changes. It seems like you could improve this algorithm without too much trouble. For example, it feels like if the query was located solely through indexes, it should be able to do cache invalidation on an update to those index hits rather than on the entire table.<p>I'll have to look through the code one day and see why this makes no sense.
Interesting use of the 20-second cookie. What happens when they scale to data centers in Europe, Asia, and South America? Does it become a arbitrary-second cookie depending on where the user is?<p>Nonetheless, I can appreciate how a simple approach solves the problem. If these are the most dramatic scaling issues that facebook faces, then this provides strong support to the argument that you shouldn't focus too much on scaling and optimization when first building your site. There are probably better uses of your early time.
There's another easier way built into memcached:<p>When you issue a delete you can specify "the amount of time the client wishes the server to refuse 'add' and 'replace' commands"<p>Maybe they couldn't afford to increase the read load so much but this seems easier than rewriting mysql's replication engine.
<a href="http://golanzakai.blogspot.com/2008/11/memcached-replication-and-namespaces.html" rel="nofollow">http://golanzakai.blogspot.com/2008/11/memcached-replication...</a><p>Here is a setup where you can scale with memcached