Interesting but all pretty straightforward. The more interesting question around caching is how to keep the cache fresh - do you just cache for short amounts of time and let them expire, or do something clever at the front end (such as tagging cache items) so that a set can be removed on batch when the database is updated. Further, what exactly is being cached? database result-sets, serialised objects or something else?

We cache everything. Database queries, objects, rendered views. Anything that gets processed we try and cache. The length of time depends on what it is and where its presented. It's tough to put a rule on setting expiration time.

Objects (users, pictures, videos, articles, etc.) are cached for 24 hours. We cache the row of results and rebuild the object from that. They are busted if they are updated, otherwise the data usually doesn't change.

Database result lengths depend on what they are used for. Anywhere from 15 minutes to several hours or days. Data that is requested more frequently (homepage) usually busts more frequently then say the user profiles page which gets far less attention.

Every section on our site is rendered in different views. These also depend on the frequency of use. The comments section of a video is cached for a short period of time. A recently released video is busting comments every few seconds or minutes as users comment on it. Something like the physical contents of an article can be cached longer, because once its written it usually doesn't change. It's pretty subjective.

We experimented with "cache groups". Which were collections of cache keys that were related. From there we could bust tons of related keys. We found the extra work of tracking the keys to not be beneficial for our site. Most of our data isn't related or mission critical, If something is stale for a few minutes it usually doesn't make a difference. Tracking the extra keys became too complex.