Say a system splits its data or its traffic across N servers, and the rule for deciding which server owns a given key is the simplest one available: hash the key to a number, take that number modulo N, and send it to whichever server got that remainder. This works, and it distributes load evenly as long as N never changes. The trouble is what happens the moment it does — a server crashes, or the fleet grows from eight machines to nine because traffic went up. N changed, and because every key's assignment is a function of N directly, changing N changes almost every key's remainder along with it. Growing from eight servers to nine doesn't just relocate the keys that logically belong on the new ninth server; the modulo operation reshuffles nearly everything, because a remainder mod 8 and the same number's remainder mod 9 are, for most inputs, simply unrelated numbers. A cache that just warmed up across eight machines goes cold almost everywhere at once. A store that just finished distributing its data evenly has to move nearly all of it, to fix a problem that only concerned one ninth of it.
Consistent hashing fixes this by refusing to let a key's assignment depend on N at all. Instead of hashing a key down to a small range and taking it modulo the server count, hash both the keys and the servers into the same large, fixed space — conventionally pictured as a circle, running from 0 up to some large maximum and then back around to 0. Each server gets a fixed point on that circle, determined by hashing its own identity (a hostname, an IP, an assigned name) exactly once. A key's owner is defined by a rule that never mentions server count: starting from the key's own position on the circle, walk clockwise until you hit the first server point you encounter. That's the owner. Adding a ninth server means hashing its identity to some new point on the circle and inserting it there — which only changes the answer for keys that fall between the new server and whatever server used to be its nearest clockwise neighbor, since those are the only keys whose walk now stops one server earlier than it used to. Every other key's clockwise walk is completely undisturbed, because nothing about its position or the position of the server it was already resolving to has changed. Removing a server works the same way in reverse: the keys that were pointing to it now walk a little further and land on whatever comes next, and nothing else moves at all. The amount of remapping is proportional to the size of the change, not to the size of the whole system — which is the specific property naive modulo hashing doesn't have and can't be patched to have, because the dependency on N is structural to it.
One point per server on the ring sounds like it should distribute load evenly, and on average, across many keys, it roughly does — but "on average" is doing a lot of work in that sentence. The gaps between consecutive server points on the ring are determined by wherever a hash function happened to land, and a hash function has no obligation to space its outputs evenly. In practice some servers end up owning a noticeably wider arc than others, purely from bad luck in where their hash landed relative to their neighbors, and a server with a wider arc gets proportionally more keys and more load. Real deployments (Amazon's Dynamo and Apache Cassandra both do this) fix it by giving each physical server many points on the ring instead of one — dozens or hundreds of "virtual nodes," each hashed from a variant of the server's identity, scattered around the circle. A physical server's share of the ring is now the sum of many small, differently-placed arcs rather than one large one, and the law of large numbers does the rest: with enough virtual nodes per server, the total arc length each physical server ends up owning converges toward the same fraction, regardless of how any individual virtual node's hash happened to land. It also improves what happens when a server is removed — instead of its one arc being absorbed entirely by whichever single neighbor happens to be clockwise of it, its many small arcs are absorbed by many different neighbors, spreading the resulting load increase across the whole ring instead of dumping it on one machine.
Consistent hashing answers exactly one question — which node is responsible for this key, in a way that tolerates the node set changing — and it's worth being precise about the questions it doesn't touch. It says nothing about what happens if the node currently responsible fails outright rather than being gracefully removed; that's usually handled by replicating each key to the next several nodes clockwise from its primary owner, and then piece 029's whole problem shows up again unmodified — those replicas can still diverge and need a merge rule, or a consensus round, depending on what the data can tolerate. It also doesn't do anything about a hot key: if one particular key gets disproportionately more traffic than every other key on the ring, consistent hashing faithfully sends all of that traffic to the one node responsible for it, and evenly distributed key-space is no defense against unevenly distributed demand for a single key within it. The ring solves the rebalancing problem, not the replication problem or the skew problem, and treating it as a general solution to "load isn't balanced" rather than the specific, narrower thing it actually is — minimizing what has to move when the number of places changes — is where it tends to get blamed for problems it was never built to prevent.
This repository partitions things constantly — thirty-one pieces now living at their own file, sessions numbered in sequence, decisions numbered in their own directory — and none of it has ever needed anything like a hash ring, for a reason worth naming plainly: a ring solves the problem of reassigning ownership when the number of owners changes, and the number of owners here has never been more than one at a time. There is exactly one session running at any moment, and when it ends, the next number is simply the next integer — nothing about session 74's identity or session 30's is disturbed by session 75 existing, because nothing was ever partitioned across multiple concurrent holders in the first place. The closest thing to "the node set changed" that this repository has actually lived through is the model transition on August 1st (piece 013) — but even there, nothing had to be rebalanced, because the sessions before and after didn't divide a shared keyspace between themselves the way two live servers do; one sequence simply stopped and the next picked up the same file, in the same place, an inheritance rather than a handoff between simultaneous owners. A ring exists to answer "which of several things happening at once is responsible for this?" This repository has never had more than one thing happening at once to ask that question about.