Poor man’s memcached for Windows Azure

UPDATE: After reading this post you can read about the scalability of this solution, posted based on some comments.

Part of working with the Windows Azure guidance team is not only about writing but it’s also about helping customers and understanding real life problems. This help us validate and enrich the content.

One of the customers we are helping has an hybrid solution in Windows Azure where there is a backend running on-premises that pushes information to a frontend running on Windows Azure in ASP.NET. This information is stored in blob storage and then served from the web role. To avoid going every time to the blob storage, though, they want to cache the information. But whenever you cache, you have to handle the expiration of the item you are caching, otherwise it never gets updated. That’s one option, cache it for X minutes. But the ideal would be to control the caching and whenever the information gets stale, update the cache. This is easy if you use an ORM like NHibernate or if you are using SqlCommands and SqlCacheDependency or if you use something like memcached or the AppFabric velocity. However it gets more difficult if you have other kind of resources to cache and if the web application runs in a farm.

Using Windows Azure queues to invalidate ASP.NET Cache

Maybe you need something smaller. This is what I implemented, I just posted on git two classes that can be used in a Windows Azure Web Role running ASP.NET as a very basic distributed caching mechanism. The following picture shows how it works at a high level.

Usage

Using it requires two things

1. Start the monitor (that listens to the queue). Write this code either in the WebRole entry point or in the Global.asax Applicaiton_Start.

   

2. Use the regular ASP.NET Cache API but providing the CloudQueueCacheDependency with a key

   

Example

I uploaded this to Windows Azure and provisioned two instances of a web role and this is the result

Web Role instance 0	Web Role instance 1

By sending a message to the invalidatecache-distributedcache-web-in-0 queue we invalidate the item “test” in cache in the 0 instance. This corresponds to the Cache1 label. If we send “test2” message, we would invalidate the Cache2 item.

The cache expired and an updated datetime is shown.

Web Role instance 0	Web Role instance 1

Conclusion

By using this technique you can have a distributed system where the backend makes an update on-premises, pushes something to the cloud and it invalidates the cache by posting a message to a queue. I didn’t worry too much about being fault tolerant in the monitor simply because in the worst case the item keeps alive in the cache and you can repost a message.

Download the code from here

DISCLAIMER: the code is provided as-is and has not been tested under stress conditions. Use it at your own risk.