A coworker of mine wrote a series of posts on how to build a consistent hashing ring and expand it with the concepts or weighted nodes and availability zones.
I remember someone pointing out your AudioGalaxy server cluster at the north austin datacenter (I think it's the one that became SunGard). I just said "wow". You still in Austin?
Yeah, that was pretty cool for the time, at least until I had to unrack every single one and drive it back to our office. This is what it looked like after that:
If you're using memcached, using consistent hashing is largely a matter of configuration on the client side (although it's worth understanding how it works and why you want it). Pretty much any memcached client that's built on libmemcached comes with it although most aren't using it by default; the overhead of calculating the ring is significant and needs to be thought about e.g where you store it - not something you want to do on every request.
redis also supports consistent hashing in many of its drivers (including the Ruby one). It also supports a nifty way to only use part of the key as the consistent hashing key so that you can ensure certain data is stored on the same server. For example, if you use the key "mydata-{123}" only the "123" part will be used by the consistent hashing algorithm. Of course, Riak is also a good example of consistent hashing.
It always boggles my mind that more people don't know this. Every presentation I give, I always try to put in a slide about consistent key hashing, because it is one of the easiest things to get right and yet something I see most everyone get wrong (including myself the first time around).
