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.