Skip to content
andymccurdy edited this page Feb 17, 2011 · 5 revisions

What is the best way to handle cache invalidation? Is this the correct process?

  1. Check hash to see if file has changed and needs to be uploaded.
  2. If changed or missing on remote, push file.
  3. If this is the first push of the file then we are done, move on to next file.
  4. If the file had already existed on S3, add to list of files to invalidate.
  5. At the end of syncing, send cache invalidation message to S3. (Check on message length limits, there are several with SDB/EC2, and probably for CloudFront)

Alternative Approach with File-Specific Versions

An alternative approach is to maintain a MEDIA_VERSIONS.json file on S3. This is simply a map of 'path/to/media.js' => VERSION_NUMBER (an integer). A MediaVersioner class would then know how to read/write the JSON file and provide a method of converting 'path/to/media.js' to 'path/to/media_{VERSION_NUBMER}.js. This way no CloudFront invalidation needs to happen.

Deployment steps would be:

  1. Load the MediaVersioner to get all current media versions.
  2. Find all files missing on remote or that have changed.
  3. For each file, increment its version in the MediaVersioner and upload it to S3.
  4. Tell the MediaVersioner to save it's state to S3.

Additionally, the {% js %} and {% css %} (and perhaps other?) templates tags change slightly such that they can speak to the MediaVersioner. The first request to the MediaVersioner connects to the S3, retrieves and deserializes the JSON file. Subsequent requests are simple dictionary lookups to translate base path to path-with-version baked in.

Clone this wiki locally