My issue with the metadata approach is that it can lead to unnecessary traffic, and while this traffic is small, could be a scalability problem. I very much prefer the consistent hashing approach if we can make it work for us. Using two hash functions to map an Fqn to two different servers is one approach, but this is hard when you want > 1 backup copy. Regarding memcached in relation to JBC, I actually see JBC as a memcached server rather than a client. E.g., Bela's memcached server code could act as a "front end" to JBC, and instead of putting stuff in a CHM, it could put stuff into a JBC instance. This buys us: 1. The ability to use different types of clients talking to JBC (any memcached client library should work) 2. The ability to be colocated in-VM as well, for a more p2p-like setup To make this work we would need clients to be aware of the consistent hashing algo, so it could direct requests to the relevant server (as an optimisation), and for clients that don't do this (as well as colocated clients) the JBC instance would need a subclass of the ClusteredCacheLoader that has the consistent hashing algo. We then automatically have cache instances acting as L1 caches if they aren't the "host" cache for a particular fqn, and automatically would have L1 cache invalidation (assuming the cache uses INVALIDATION. REPLICATION would be pointless anyway in such a setup). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177433#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...