Justin and Thomas Wagner are talking about Caching in a Web Farm. Justin has proposed an extension to the his cache server idea includes a .NET Remoting server that fire events to the local web server caches telling them to invalidate.
I was a team that implemented a Cache-y observer-observable pattern with SQL Server and Triggers (which has been seen many times before, as well as on GotDotNet with Ron Howard's trigger-based ASP.NET Cache Invalidation on Database Change). Basically the Web Server had endpoints that register for callbacks and the SQL Server lets them know when things change.
It would be even cleaner if the only observer was the Justin's Cache Server...then it fires event back (via Remoting, whatever) to the Web Server caches. But, I digress. The real opinion I wanted to get out was that I personally believe two philosophies of cache invalidation, for simplicity, whenever possible.
One: Explicit Pull - When the the client of the cache knows when it explicitly needs the latest stuff, it includes says so explicitly. All other calls that don't include this explicit modifier, come from the cache, which may or may not invalidate over time or n number of calls.
Two: Invalidate For Equally Acceptable But Not As Time Consuming Or Complex Other Reasons - I just don't think that the trouble one usually has to go to to create foolproof interrupt based cache invaliation is worth the effort. Instead, a real business analysis of what "real time" means to the user. Follow the ubiquitous and ever useful (for my purposes) 80/20 rule. If I can get a performance hit even caching something a few seconds then use a time based invalidation.