Caching Data - API Based or Pattern Based?
Current thought process
I have been spending some time with the Velocity and ASP.NET 4.0 Cache Extensibility teams at Microsoft working with them to formalize some up and coming releases. One common thread that I just can't help but notice is the fact that the average developer simply should NOT care about the specifics around Caching. For example, when/how to lock, dependencies, static's, how to create a cache/regions, get a cache, expire vs. eviction, etc..
They should only care about this "Cache" thing, that I can Get and Put data in and out of.
Types of Data
As you begin a deep dive into Caching you soon see that there are a few ways to slice and dice the caching world. The most simplistic method is to do division by the type of data you are working with. Here is a snippet from the Microsoft Velocity Documentation regarding types of data.
| Understanding the various types of data helps define the degrees of caching that are possible using "Velocity." As seen in the following table, there are three types of data that are appropriate for distributed caching: reference, activity, and resource. (Source)
|
For example:
Reference data could be Amazon's Book Catalog.
Activity data could be the User's Shopping Cart - secure, tied to that user's session
Resource data could be the Stock available for each Catalog item
Design Patterns
From an API perspective we should consider actual developer usage based on common design patterns. I would love to see a ReferenceDataCache, ActivityCache and a ResourceCache in the API. Each specific type of Cache wrapper should just take care of the internal details for me and guide me on usage. The Architectural roles in the organization can config/tweak specific cache details based on these common patterns and tied to the specific needs.
For example I want to create a AmazonBookCache which is a ReferenceCache and never worry about locking items (since its shared read, there is no need to lock anything). I also want it super-optimized for reads across the cache cluster.
I could create a ShoppingCartCache which is a ActivityCache<T>. In this type of cache, all of the methods would require the additional parameter (T) to indicate the specific User key - long, guid, or whatever your application uses to represent that specific user the activity is based on. Locking would be important so expose the relevant concurrency based Get/Put methods only – that is, remove Put() methods that do not include version information parameters.
Closing Thoughts
I understand the basic need of getting a core API working correctly and obviously it would be in Microsoft’s best interest in getting that done as soon as possible. With that said, for this API to be of any use, there is a need for a consistent set of wrappers based on common patterns which we all can rely on.
Caching is one of those seemingly easy things to put in place but in reality if it is not done correctly could have very drastic –negative- implications on the application.
1 Comment
Comments have been disabled for this content.
Kevin Clark said
Well said Rob. Couldn't agree more. Programmers and developers should focus on what they do best. The caching solution should be very easy to implement and manage. If a consensus on what should be a norm for core API development can be reached this would be of great benefit. I hope we get to see this implemented by the caching solution providers.