Caching is a fine thing. Except when its not.

After updating some audio that is played to people who phone our Twilio app, we ran into an issue with callers still hearing the old prompts. Our app manages jillions of prompts, and for a variety of reasons we chose to make the prompt filenames static, adhering to a naming convention that uniquely identifies each of our customers. In our case, customers sometimes add static links to ‘their’ audio and we don’t want those links to ever change. (Web browsers, for example, grab the updated audio just fine.)

We don’t update prompts that often, but when we do, we need them to go ‘live’ immediately.

The issue is that Twilio (reasonably) caches remote audio urls to avoid having to reload them every single time an audio is played.

Twilio technical support offered a very workable solution… their urls are cached with the query string in the url, so if we add ?version=XXX at the end of our audio urls, each time we bump XXX it forces a reload of the “new” file into Twilio’s cache.

In our case, we added a single system-wide counter that we bump when anything changes. We’ll eventually get around to maintaining a version number for each file.