manage.get.gov/docs/architecture/decisions/0025-caching
2024-02-14 13:57:04 -07:00

37 lines
2.3 KiB
Text

# 24. Production Release Cadence
Date: 2024-14-02
## Status
In Review
## Context
We experienced problems with our caching infrastructure early in our November launch. In response, we turned off caching across the application. We would like to examine ways to utilize caching again without incurring the same issues.
The Incident:
Originally, Cloudfront was utilized to provide caching capabilities in our application. All incoming HTTP requests first go through a Cloudfront endpoint, which has a caching infrastructure enabled by default. Cloudfront then decides whether to pass each request to our running Django app inside cloud.gov or if it will respond to with cached data. The big problem with this feature is Cloudfront's caching has a default timeout of 24-hours, which we cannot control. This led to issues on our November launch; Incidents reported include the following...
- Users couldn't utilize login.gov properly and had to wait a day before they would be able to login. This was traced back to the 24-hour cache timeout.
- Changes made by admins would not be reflected in the app (due to the cached data not updating)
To resolve these issues, we added "no cache" headers throughout our application. Currently, every single HTTP response that comes from Django says "Cache control: no cache" in the headers, which instructs Cloudfront not to cache the associated data. This effectively removes Cloudfront caching for us.
Although we could leave our architecture as-is, we decided to investigate options for improving our use of caching (instead of just disabling it completely).
## Considered Options
**Option 1:** Cache static resources using Whitenoise
Caching static resources should pose little risk to our application's functionality. Currently, every static resource from /public/... is hitting our Django application inside of Cloud.gov. We already use a Django plugin called whitenoise that can do hash-based linking to static assets so that they can be cached forever by Cloudfront. (If the content changes, then the hash changes, then it results in a different filename.)
See ticket #1371 for more information.
## Decision
(We are going to test whether using Whitenoise improves our performance significantly enough to move forward with it)
## Consequences
(TBD)