Skip to content

CDN: Resetting Cache

Sometimes we need to go there to clean it out.

Images

Most of our images are served through ImageKit. There are few locations:

  • public-images.interaction-design.org (linked to the ixdf--images bucket)
  • public-media.interaction-design.org (deprecated, linked to the idf--assets bucket)
  1. Go to ImageKit purge cache
  2. Click New Request
  3. Type in the Full URL or URL wildcard read more

Note If you're trying to reset cache for 1-10 images, please paste in their exact URLs, one URL per line. Use wildcards only if you've replaced all or most of the images in one S3 directory.

Note: Make sure you reset the cache for the correct domain, for instance the following request won't affect anything: https://ik.imagekit.io/fsagsz7h3vl/images/courses/hds/* But this one does: https://public-media.interaction-design.org/images/courses/hds/* Although both of them are serving the same image.

Videos

The processed video files are served via CloudFront to ensure low latency and high-transfer speeds.

You can invalidate any cached video served by CloudFront by finding it in the Nova admin panel and starting the “Reset cache” action.

Non-versioned asset

When icons, static images or other rarely-manually-updated content changes, the CDN will not serve the new version. in that case, we need to invalidate/purge the cache (partially).

Guide:

  • get the AWS URL(s) that need the cache invalidated, e.g. https://public-assets.interaction-design.org/documents/IxDF_Referral_Handbook.pdf

  • log into AWS Cloudfront Dashboard This requires currently AWS web; root user login from the Development Red Zone In LastPass

  • select the correct Distribution, identifiable via the Alternate domain names e.g. public-assets.interaction-design.org

  • change to the Invalidations tab, press Create invalidation button

  • add the path to the file to invalidate, e.g. /documents/IxDF_Referral_Handbook.pdf

  • confirm by pressing Create invalidation button

  • you get redirected to the Invalidations Dashboard where you can follow its processing state

  • finally: test the URL again (be aware, there can be a delay up to 15 minutes)

  • official AWS guide is available here

Please, make sure this operation will apply all rules from CDN (anyone) as they are, and the resulting file (content & header) may not be the same if an important config has changed.

Versioned Assets

These type of assets do not need to be manually handled. As soon as the file changes, it hash/fingerprint will change in the output, resulting in a new file name that is not cached.

After configuration change

When a configuration change is made, wait for the changes to be propagated into all the CDN edges and them, flush all the CDN content.

DISCLAIMER: when doing so, if another change was done, and the cache was not fully cleared, you may face issues with images, videos, subtitles an/or other resources using CDN. When doing so, MAKE SURE you are 101% confident to rollback the changes to a previous state.

It’s important to highlight that CDN changes can take up to 15 min in normal circumstances to reflect to the members and/or visitors and also has different propagation times based on your location and availability-zone/edge load on AWS.

When doing configuration changes, be aware it is highly recommended to have 2 hours slot available to handle low to medium level issues thath can appear. In some situations, a CDN incident can take up to 5 hours to be completely fixed (time to be reported after changes, investigation, fixes, propagation, etc). Also, make sure another developer is available to assist you if something goes wrong. — @ops-team is available to help