Caching Strategies for Scaling
As your application experiences more traffic, there will be a heavier burden placed on your application servers and database(s).
Caching is a technique of removing that burden from your servers by placing it into memory for fast access. The most popular cache servers are memcached and Redis, which both store their data in a key-value format.
Caching Strategies
While caches are most commonly used to cache data stored within a database, there are a variety of other caching strategies as well. Below is the list of the common caching strategies for cloud native applications:
Database Caching
Caching of data from the database is the primary use for caches in a cloud native architecture. Required data is first checked for in the cache. If it is available, the data is used immediately, without requiring direct database access. If not, then the data is retrieved from the database and stored into the cache for later retrieval.
To ensure that data isn’t stored for too long, a time-to-live (TTL) is set to expire the cache entry. This will prevent caches from becoming too stale, forcing applications to re-retrieve the data fresh from the database after a specific period of time.
Cached data is often stored in a ready-to-use format, such as JSON or XML. It may also be stored in a serialized object format that is specific to the programming language or framework used by the application. However, this prevents the cached data from being reused by different languages or perhaps even different versions of the same application or programming language. Use caution when caching objects as opposed to data in a more generalized format.
Server Page Caching
For application-generated pages, caching speeds up response time greatly. After a server-side page has been rendered, the application may choose to cache the entire page into a caching server and return it when the page is requested once again. Optionally, the use of an HTTP caching server, such as Varnish, may be used in place of a caching server to accelerate entire HTTP responses for static or dynamically-generated content.
Bear in mind that server page caching will save the entire page, including any areas that may be rendered based on the current logged-in user. This will cause strange issues where users see another user’s content, unless developers take precaution to cache pages on a per-user or per-role basis. As a result, some applications may choose to use server fragment caching instead.
Server Fragment Caching
The difficulty with server page caching is that it doesn’t always fit for your application needs, due to per-user customization requirements. Instead, servers should cache fragments of a page. This reduces the time required to fetch the associated data, run any application logic, and generate the server-side code. Server pages will be optimized by rendering these cached fragments, while allowing any per-user customization fragments to be generated on-demand. This is the most common caching strategy for server-side generated web pages that behave differently based on the current user requesting the page.