Distributed in-memory caches have been rather popular over the last few years in everything from mainstream Java applications to the fringe languages like Erlang. Continuing its rather frantic efforts to catch up with technologies predominately found in the open source world, Microsoft has introduced its own distributed cache.
Velocity is a distributed cache designed specifically for the .NET platform. Many of the features will be recognizable to those familiar with other distributed in-memory caches. It is currently available as a community tech preview.
There are two types of clients for Velocity. Simple clients only know about a single cache server. If the requested object is not available on that cache server, the cache server will fetch it from the appropriate server. Routing clients are much more involved. They always know where a particular object lives so they can query that cache server directly. The performance impact of sending all of the cache location data to a routing client hasn't been discussed. In addition to the cache servers, both types of clients support a local cache option. This still requires checking the server for stale data, but should reduce network traffic when dealing with large cache objects.
For concurrency two options exist. With optimistic concurrency, the first update wins and any further updates to the now stale object will fail. With pessimistic locking, a lock handle is returned. Until unlocked, or the timeout expires, all attempts to gain a lock will fail. Failure to obtain a lock is a non-blocking operation.
Objects can be removed from the cache explicitly, via a expiration date, or whenever memory pressure is exceeded. This last method, known as eviction, uses a least recently used algorithm.
In addition to a key, objects may have a collection of tags associated with them. There are methods to retrieve one or all objects that match a list of tags.
http://www.infoq.com/news/2008/06/Velocity;jsessionid=1A186B573B980B4638C65CDEDF143B60