Cached-Aside Pattern using Redis on Azure

Cache-Aside is a common pattern in modern cloud applications. This is a very simple and a straight forward one. The followings are the characteristics of the pattern.

  • When an application needs data, first it looks in the cache.
  • If the data available in the cache, then application will use the data from the cache, otherwise data is retrieved from the data store and the cache entry will be updated.
  • When the application writes the data, first it writes to the data store and invalidates the cache.

How to handle the lookups and other properties and events of the cache are independent, meaning the patters does not enforce any rules on that. These diagrams summarize the idea.

  1. Application checks the cache for the data, if the data in the cache it gets it from the cache.
  2. If the data is not available in the cache application looks for the data in the data store.
  3. Then the application updates the cache with the retrieved data.

  1. Application writes the data to the data store.
  2. Sends the invalidate request to the cache.


Project :

The above project has an implementation of this pattern.

Data objects implement an interface ICacheable and an abstract class CacheProvider<ICacheable> has the abstract implementation of the cache provider. You can implement any cache provider by extending CacheProvider<ICacheable>. GitHub sample contains code for the Azure Redis and AWS Elastic Cache implementations.

Implementation of ICacheable :

Implementation of CacheProvider<ICacheable>:

Implementation of AzureRedisCacheProvider :

The template also includes Cache Priming in Global.asax. This could be used to prime your cache (loading the mostly accessed data in the application start)


Redis on Azure : Architecting applications on Redis and its data types

Redis is the recommended option in the Azure PaaS caching techniques (Read why). Still Azure provides and supports other caching options too (What are the other available options)

Redis cache is available in Azure. View the Azure Redis Documentation and Pricing details.

When talking about caching, often we think of key value pair store. But Redis is not just a key value store, Redis has its own data types and support transactional operations.

Having a clear idea about the Redis cache and Redis data types will certainly help us designing applications in more Redis way.

Clone this git repository to get the idea about Redis data types.

The application demonstrates a crude sample of posting messages. Users can post messages and like the posts. Most recent posts and most liked posts are shown in different grids. Also users can tag posts.

Key Value pairs, Lists, (capped lists), Redis functions, Hashsets and Sets are used in the sample.

Read more on Redis data types

I will update source with more samples and information. Apart from the Redis features in the Azure portal we get comprehensive dashboards about the cache usage, cache hits, cache misses, reads, writes, memory usage and many more.

Which Azure Cache offering to choose ?

The above is one of the burning questions from Azure devs, and with all other cache offerings from Microsoft Azure along with their sub categories the confusion gets multiplied on what to choose.

Currently there are (and probably not for a much longer in the future) 3 types of cache services available in Azure.

  • Azure Redis Cache
  • Managed Cache Service
  • In-Role Cache (Role based Cache)

Ok now let me the answer the question straightly (especially if you’re lazy read the rest of the post) – For any new development Redis cache is the recommended option

So what is the purpose of the other 2 cache offerings ?

I blogged about the Managed Cache Service and Role based Cache some time back. (I highly recommend to read the article here before continue the reading) . The below diagram has the summary.



Read this blog post to get to know how to create and use Role based cache and Azure Managed Cache service.

Pricing, future existence and other details

Role Based Cache :

Since the Role based cache is technically a web/worker role regardless of whether it is co-located or dedicated, it is a cloud service by nature. So you create a cloud service in Visual Studio and deploy it in the cloud services, you can see and manage these roles under the cloud service section in the portal. And cloud service pricing is applied based on the role size. Role based cache templates are still available in Azure SDK 2.5 and you can create them, but not recommended. The future versions of the Azure SDK might not have the Visual Studio project template option for the Role based cache.


Azure Managed Cache Service :

The blog post shows how to create the Managed Cache in the Azure management portal and how to develop applications using C#.NET. But if you try to create the Managed Cache service now you will not find the option in the Azure management portal, because it’s been removed. At the time of writing of that blog it was available. The reason why it’s been removed is very obvious because Microsoft recommends Redis cache as alternative. The apps which use the Managed Cache service will continue to function properly but highly recommended to migrate to Redis Cache. Still the creation of Managed Cache option is available in Azure PowerShell. I’m not discussing about the pricing of the Azure Managed Cache service since it’s been discontinued. I have a personal feeling that Managed Cache service will soon be eliminated from Azure services, Microsoft might be waiting for that last customer to move away from Managed Cache Service 😛


Azure Redis Cache :

This is the newly available feature Redis on Windows cache option. The below link has information about the usage pricing and other information about the Azure Redis Cache.

ObjectCache – Caching

In the ASP.NET domain all the state mechanisms can be considered as caching, both in the client side (view states, query strings, cookies) and in the server side (application state, session state and the Cache object itself.) You can define the classes and properties as static to get the effective functionality of caching. In ASP.NET the Cache object is HttpContext.Cache and .NET 4 introduced the ObjectCache to be used in non ASP.NET applications. This post will walk you through about the ObjectCache.    Learn about Windows Azure Caching.


This is included in the System.Runtime.Caching assembly. MemoryCache is the concrete implementation of this library. The following method provides a quick glance on how ObjectCache can be used.

   1: public static void PutInCache(string key, object value)

   2: {


   4:     var cache = MemoryCache.Default;

   5:     var policy = new CacheItemPolicy()

   6:     {

   7:         AbsoluteExpiration = new DateTimeOffset(DateTime.Now.AddMinutes(5)),

   8:         Priority = CacheItemPriority.Default

   9:     };


  11:     Console.WriteLine("Cache Size for the application in MB - {0}", cache.CacheMemoryLimit / ( 1024 * 1024) );

  12:     Console.WriteLine("{0}% cache memory is used.", (100 - cache.PhysicalMemoryLimit));


  14:     cache.Remove(key);


  16:     cache.Add(key, value, policy);


  18:     int result = (int) cache.Get(key);


  20: }

CacheMemoryLimit property gives the allocated cache memory for the specific instance of your application, where as PhysicalMemoryLimit give the unused space of the cache in percentage. When the cache memory  reaches beyond the CacheMemoryLimit then cache values are removed automatically, we can track this and take actions by registering a callback for the cache item removal.

Cache have 2 types of expiration policies. AbsoluteExpiration is the definite time after which there’s no guarantee for the item to be available in the cache memory, SlidingExpiration is where if there’re no access to the particular cache item within the specified time period there’s no guarantee for that item to be available. These 2 are very common and available in the HttpContext.Cache as well.

Cache has a priority which takes the value of the CachItemPriority enum. This enum has 2 values Default and Not Removable. Default is the default set up, means when you do not mention any value this would be applied. Default ensures the default behavior of the cache. Not Removable is used to instruct the system not to clear the values from the cache even when the system runs low in memory. These values should be cleared explicitly.

Windows server 2008 Core doesn’t support the ObjectCache and some Itanium implementations also do not support ObjectCache. Windows Server 2008 R2 with SP1 and later versions (including Windows 8.1) support ObjectCache.