In a previous post I discussed the ability of  dynamic data to be accelerated, what enables WebAccelerator to cache dynamic or deterministic data is invalidations.  When content changes you don't want to be serving stale data the invalidation process ensures this doesn't happen.  An invalidation message tells the cache that the content that is currently stored is now expired and the next request for the content needs to be validated with the origin server.  This is normally performed via a conditional GET (if-none-match or if-modified-since) being issued to the web server.

Invalidation of content can be done manually or it can be done automatically.  WebAccelerator provides two methods of automatic invalidation policy invalidation and  ESI invalidation.  Both of these methods allow granular control over what is invalidated and when.  Policy invalidations are triggered by an action within the application.  Let's go back to my favourite example DevCentral and examine a blog post.  The blog posts on DevCentral change every time a user comments on the post, otherwise these are fairly static.  These pages would be a good candidate to be cached for a lengthy period of time say 7 days.  A trigger can be defined in a policy so that when a user posts a comment the post is invalidated this ensures that the next time the post is viewed the cached version without the comment is not delivered and the comment appears. 

ESI invalidations are not driven by changes within the application but rather when by the creation or publication of new content on back end systems.  Say you have an e-commerce site and a new version of the home page is published once a week highlighting the weekly specials -the home page can be served from cache until the new version is published.  To invalidate the home page as soon as the new version is published an invalidation message can be sent from the publishing engine to the WebAccelerator.  The next time the home page is requested the new specials will be presented not the old ones. 

Invalidations are very powerful and allow more items to be served from cache but as with everything these should be tested thoroughly before being put in production to ensure that they are working properly and invalidating the correct content.  You don't want to accidentally invalidate the entire cache ever time a comment is posted.