Caching or say a cache, is a high-speed data storage layer which stores a subset of data, so that future requests from other users for that data are delivered faster than requesting it form the primary storage destination (Where the resources are hosted).

So when caching is implemented, what users are seeing on the website is actually an already-seen version of it. For example, let’s say one user is visiting a page called index.html. For the very first visit, the browser and server will request all relevant informations on index.html from the server. After that, there will be a cached version of this index.html page. If there are users visiting the same page, we will just serve them the same version that the previous users have requested without going to the primary storage location.

There are many ways and places we can implement caching. Some of the most common are listed below:

Database Caching

The performance, both in speed and throughput that your database provides can be the most impactful factor of your application’s overall performance. And despite the fact that many databases today offer

Database Caching is the process of storing the information in high performance store generally memory and applying the subsequent retrieval and updates to the same high performance store. A cache is generally placed between the applications and the databases and all interactions happen with the cache rather than the database directly.

Many caching strategies are adopted depending on the problem to be solved but the important ones are as follows –

• Cache Aside – The application looks for the data in the cache first as cache sits along side the database. If the data is not available in the cache, a call to the database is made and the data is returned to the application and simultaneously populated in the cache.The subsequent request for the same data will be fulfilled by the cache.To address the data staleness issue, a time to live (TTL) is set for the cache and at the expiry of TTL, the data in the cache is refreshed again.
• Read Through – The cache sits between the application and the database. The application always requests the cache for the data and if the data is not available in the cache, cache makes a call to the database to populate it.
• Write Through – The cache sits between the application and the database and every write is routed to the database through the cache. The cache writes the data to the database immediately.
• Write Back – The cache sits between the application and the database. Instead of writing the cached data to the database immediately, the data is written to the database on prior decided frequency.
• Write Around – All writes happen directly to the database with only the data being read, ending up in cache.

Content Delivery Network (CDN)

When your website’s traffic is coming from all over the world, it would not be providing great user experience if you just serve them from one server. Typically in this situation a content delivery network or so called CDN will be implemented.

A CDN provides you the ability to utilize its global network of edge locations to deliver a cached copy of web content such as videos, webpages, images and so on to your customers. To reduce response time, the CDN utilizes the nearest edge location to the customer or originating request location in order to reduce the response time. Throughput is dramatically increased given that the web assets are delivered from cache. For dynamic data, many CDNs can be configured to retrieve data from the origin servers.

Some of the best practices that would help you optimize the cache hit ratio when leveraging a CDN cache includes

• Cache only static content: As a best practice to improve performance, when you enable Cloud CDN, you need to choose the right cache mode for your application. The most flexible and generally preferred method to manage cache rules is by using the cache control header. If you are not currently familiar with using origin cache-control headers, the best practice recommendation is to allow Cloud CDN to automatically cache static content.
• Don’t cache user-specific content: This is a given. You wouldn’t want a user to see other user’s profile on their profile page. While in some cases, browsers can cache user-specific content. Don’t use CDN to cache user-specific content.
• Implement a cache policy and use a custom cache key: The cache key determines whether a viewer request to a CDN edge location results in a cache hit. The cache key is the unique identifier for an object in the cache. Each object in the cache has a unique cache key. A cache hit occurs when a viewer request generates the same cache key as a prior request, and the object for that cache key is in the edge location’s cache and valid. When there’s a cache hit, the requested object is served to the viewer from a CDN edge location, which has the following benefits:
  • Reduced load on your origin server
  • Reduced latency for the viewer

Domain Name System (DNS) Caching

Every domain request made on the internet essentially queries DNS cache servers in order to resolve the IP address associated with the domain name. DNS caching can occur on many levels including on the OS, via ISPs and DNS servers.

Session Management

HTTP sessions contain the user data exchanged between your site users and your web applications such as login information, shopping cart lists, previously viewed items and so on. Critical to providing great user experiences on your website is managing your HTTP sessions effectively by remembering your user’s preferences and providing rich user context. With modern application architectures, utilizing a centralized session management data store is the ideal solution for a number of reasons including providing, consistent user experiences across all web servers, better session durability when your fleet of web servers is elastic and higher availability when session data is replicated across cache servers.

Application Programming Interfaces (APIs)

Today, most web applications are built upon APIs. An API generally is a RESTful web service that can be accessed over HTTP and exposes resources that allow the user to interact with the application. When designing an API, it’s important to consider the expected load on the API, the authorization to it, the effects of version changes on the API consumers and most importantly the API’s ease of use, among other considerations. It’s not always the case that an API needs to instantiate business logic and/or make a backend requests to a database on every request. Sometimes serving a cached result of the API will deliver the most optimal and cost-effective response. This is especially true when you are able to cache the API response to match the rate of change of the underlying data. Say for example, you exposed a product listing API to your users and your product categories only change once per day. Given that the response to a product category request will be identical throughout the day every time a call to your API is made, it would be sufficient to cache your API response for the day. By caching your API response, you eliminate pressure to your infrastructure including your application servers and databases. You also gain from faster response times and deliver a more performant API.

Caching for Hybrid Environments

In a hybrid cloud environment, you may have applications that live in the cloud and require frequent access to an on-premises database. There are many network topologies that can by employed to create connectivity between your cloud and on-premises environment including VPN and Direct Connect. And while latency from the VPC to your on-premises data center may be low, it may be optimal to cache your on-premises data in your cloud environment to speed up overall data retrieval performance.

Web Caching

When delivering web content to your viewers, much of the latency involved with retrieving web assets such as images, html documents, video, etc. can be greatly reduced by caching those artifacts and eliminating disk reads and server load. Various web caching techniques can be employed both on the server and on the client side. Server side web caching typically involves utilizing a web proxy which retains web responses from the web servers it sits in front of, effectively reducing their load and latency. Client side web caching can include browser based caching which retains a cached version of the previously visited web content.

General Cache

Accessing data from memory is orders of magnitude faster than accessing data from disk or SSD, so leveraging data in cache has a lot of advantages. For many use-cases that do not require transactional data support or disk based durability, using an in-memory key-value store as a standalone database is a great way to build highly performant applications. In addition to speed, application benefits from high throughput at a cost-effective price point. Referenceable data such product groupings, category listings, profile information, and so on are great use cases for a general cache.

Integrated Cache

An integrated cache is an in-memory layer that automatically caches frequently accessed data from the origin database. Most commonly, the underlying database will utilize the cache to serve the response to the inbound database request given the data is resident in the cache. This dramatically increases the performance of the database by lowering the request latency and reducing CPU and memory utilization on the database engine. An important characteristic of an integrated cache is that the data cached is consistent with the data stored on disk by the database engine.