Caching Strategies — Simplified
It is important to understand caching strategies to decide which suits the application best, because every application is different and so are the strategies. Let’s discuss few caching strategies and implantation details below.
Cache Aside
In cache aside strategy, the application is responsible for reading and writing from the database and the cache doesn’t interact with the database at all. The application checks the cache first if the required information is available. If it is available, it is marked as cache hit. The data will be read from cache and returned to the client. If the information is not available, it is marked as cache miss. In this case, the application hits the Datastore to get the information and returns it to the client. Also, it is stored in the cache for future use.
Write-Through Cache
In this strategy, the data is written simultaneously to cache and memory. This is more reliable as the data in the cache is never stale. Every write involves two steps, write to the cache, and write to the database. This increases the write latency. That said, the end user is more tolerant while updating data than when retrieving data. The disadvantage of this approach is the increased cost of maintenance. Not all data are frequently read. This results in resource wastage. Adding TTL is an option to minimise this wastage.
Adding TTL
Time to live (TTL) is the time (integer value) that a data is stored in a caching system before it is deleted. By adding TTL value to each write, you can get the advantages of the strategy at the same time avoid cluttering up the cache with unwanted data. TTL is set via HTTP headers, such as Cache-Control Header, and is measured in seconds. For example, the value “Cache-Control: max-age=30” is a directive for a given resource to be refreshed every 30 seconds before time to live is exceeded.
Read-Through Cache
In this method, the cache sits in line with the datastore. Whenever there is a cache miss, the missing data is fetched from the datastore and gets returned to the application, so that the client is served. This works best for read heavy applications when the same set of application is requested several times. For example, a news story that needs to be loaded over and over by different users on different devices. The main problem with this approach is the first hit will always be a cache miss thereby loading it slower than normal.
Write-Back
In this server caching strategy, the application writes the information to the cache that immediately acknowledges the changes, and after some delay, it writes back the data to the datastore. It is a good strategy for write-heavy workloads that improves the write performance. It can tolerate moderate database downtime. The major disadvantage is, if there is a cache failure, the data may get permanently lost.
HTTP Caching
Fetching resources over the network is expensive. The page won’t be loaded until the critical resources are loaded completely. So now the question is, how to avoid unnecessary network calls. HTTP caching is the first step of defence.
In fact, there is no single API called HTTP cache. It’s a general name for a collection of web APIs.
· Cache-Control
· ETag
·Last-Modified
All HTTP request that the browser makes are first routed to the browser cache to check whether there is valid cache response for fulfilling the request. If there is a match, the response is returned from the cache which avoids both the network latency and data cost.
Server revalidation for unversioned URLs
Not all URLs loaded are versioned. Maybe you are not able to add a build step prior to deploying the web app and so you cannot add hashes to the asset URLs. Also, HTML files cannot contain versioning information as no one will remember your app URL like this https://example.com/index234234.html
The following Cache-Control values can help you fine-tune where and how unversioned URLs are cached:
· no-cache. This instructs the browser that it must revalidate with the server every time before using a cached version of the URL.
· no-store. This instructs the browser and other intermediate caches (like CDNs) to never store any version of the file.
· private. Browsers can cache the file, but intermediate caches cannot.
· public. The response can be stored by any cache.
Stale while revalidate (SWR)
Stale-while-revalidate (SWR) caching strategies provide faster feedback to the user of web applications, while still allowing eventual consistency. Faster feedback reduces the necessity to show spinners and may result in better-perceived user experience.
stale-while-revalidate and the max-age parameters can be set in the Cache-Control of the HTTP response header. A cached response to an HTTP request that is older than max-age is considered as stale. In case of a stale response, if the age of the cached response is within the window of time covered by the stale-while-revalidate setting, the stale response is returned in parallel to a revalidation request being performed. The response to the revalidation request replaces the stale response in the cache. If the cached response is older than the window of time covered by the stale-while-revalidate setting, the browser will instead retrieve a response directly from the network and populate the cache with that response. Browsers which do not support stale-while-revalidate silently ignore that configuration value and use max-age.
Let’s take the below example where the max age is 10 sec and WSR is 59 sec.
Cache-Control: max-age=10, stale-while-revalidate=59
