the cache that never hit
cached downloads were taking up 26GB while every request rebuilt the file. the freshness check depended on a timestamp that downloading itself changed.
A failed download led me to a production server with its disk at 99%. There were 26GB of cached files, but the application was not reusing them.
The course pipeline built a large ZIP when a user downloaded a finished deliverable. Some archives were around 2GB. Caching them was supposed to avoid rebuilding the same file for the next request.
the timestamp problem
The freshness check compared the archive’s build time with the job’s last-activity timestamp. Downloading also updated that timestamp.
The sequence was:
- A user requests a download.
- The cached archive is older than the job’s last activity, so the app rebuilds it.
- The app saves and serves the new archive.
- The download updates last activity again, making it newer than the archive.
The next request therefore treated the file as stale, even though the course content had not changed.
why it lasted
Downloads generally worked until the disk filled up. They were slow, but the files were large enough that the delay seemed plausible. The presence of files in the cache directory also made it look as though caching was working.
I needed to check whether requests actually reused those files. The directory size could not answer that.
the change
I changed the freshness check to use a signature of the inputs that determine the archive’s content. Download activity no longer makes an unchanged deliverable stale.
The useful check is a repeated download of the same unchanged job: does it serve the existing archive? Then change an input and confirm that it rebuilds. Those two cases tell me much more than the existence of a cache folder.
based on build notes, edited with AI assistance.