Code Library

A cache provides high throughput, low-latency access to commonly accessed application data by storing the data in memory. For a cloud app, the most useful type of cache is a distributed cache, which means that the data is not stored in the individual web server's memory but on other cloud resources, and the cached data is made available to all of an application's web servers (or other cloud VMs that are used by the application).

When the application scales by adding or removing servers, or when servers are replaced because of upgrades or faults, the cached data remains accessible to every server that runs the application.

By avoiding the high-latency data access of a persistent data store, caching can dramatically improve application responsiveness. For example, retrieving data from cache is much faster than retrieving it from a relational database.

A side benefit of caching is reduced traffic to the persistent data store, which may result in lower costs when there are data egress charges for the persistent data store.


When to use distributed caching
Caching works best for application workloads that do more reading than writing of data and when the data model supports the key/value organization that you use to store and retrieve data in cache. Caching is also more useful when application users share a lot of common data; for example, cache would not provide as many benefits if each user typically retrieves data unique to that user. An example where caching could be very beneficial is a product catalog, because the data does not change frequently and all customers are looking at the same data.

The benefit of caching becomes increasingly measurable the more an application scales, because the throughput limits and latency delays of the persistent data store become more of a limit on overall application performance. However, you might implement caching for reasons other than performance as well. For data that doesn't have to be perfectly up to date when shown to a user, cache access can serve as a circuit breaker for when the persistent data store is unresponsive or unavailable.


Popular cache population strategies
To be able to retrieve data from cache, you have to store it there first. There are several strategies for getting the data you need in a cache into the cache:

• On demand/cache aside The application tries to retrieve data from cache, and when the cache doesn't have the data (a “miss”), the application stores the data in the cache so that it will be available the next time. The next time the application tries to get the same data, it finds what it's looking for in the cache (a “hit”). To prevent fetching cached data that has changed in the database, you invalidate the cache when making changes to the data store.

• Background data push Background services push data into the cache on a regular schedule, and the app always pulls from the cache. This approach works great with high-latency data sources that don't require that you always return the latest data.

• Circuit breaker The application normally communicates directly with the persistent data store, but when the persistent data store has availability problems, the application retrieves data from cache. Data may have been put in cache using either the cache aside or background data push strategy. This is a fault-handling strategy rather than a performance-enhancing strategy.


To keep data in the cache current, you can delete related cache entries when your application creates, updates, or deletes data. If it's all right for your application to sometimes get data that is slightly out of date, you can rely on a configurable expiration time to set a limit on how old cache data can be.

You can configure absolute expiration (the amount of time since the cache item was created) or sliding expiration (the amount of time since a cache item was last accessed). Absolute expiration is used when you depend on the cache expiration mechanism to prevent data from becoming too stale. Regardless of the expiration policy you choose, the cache will automatically evict the oldest (least recently used, or LRU) items when the cache's memory limit is reached.

Source of Information : Building Cloud Apps With Microsoft Azure