Since its inception, ASP.NET has had a native Cache object, which is designed to make it easy for developers to store global data accessible from any present and future sessions. The Cache represented a quantum leap from the old-fashioned Application object, which is still supported in ASP.NET 4 for backward compatibility. The Application object is a plain global dictionary with minimal locking capabilities; the Cache object lets you prioritize cached items, supports various types of dependencies, and lets you periodically scavenge the memory and get rid of unused items. The Cache object is capable of automatically reducing the required amount of memory in case of pressure. Furthermore, it supports the same simple dictionary-based programming interface as Session state.
So what’s wrong with the Cache object? The Cache object is only ideal for applications hosted in a single server environment. An instance of the Cache class is created on a per-AppDomain basis and remains valid until that AppDomain is up and running.
If you’re looking for a global repository that works across a Web farm architecture, the Cache object isn't for you. It's interesting to note how the sentiment about this point has changed in the past few years. If you read ASP.NET books published three or more years ago, you'll likely find that the Cache object's limitations were clearly pointed out but no solution was offered or hinted at. This is because the number of Web applications requiring large caching across a Web farm was negligible up until a few years ago. Today, we live and code in a radically different world. Caching is a constant requirement and more often than not it's required by applications hosted in a farm. How would you replace the Cache object?
The first option to consider is Microsoft’s AppFabric Caching Service. If this approach doesn’t work for you, you can consider other valid options—both commercial (ScaleOut, NCache) and open-source (Memcached, SharedCache). Let’s find out more about the AppFabric Caching Service.