28.7 Where is consistent hashing used?

At the table: The round-table trick shows up wherever a crowd has to be split among helpers who come and go: wedding hosts, exam invigilators, tour guides.

In the system:

• Distributed caches: clients spread keys over Memcached servers with consistent hashing (the "ketama" approach), so adding a server doesn't empty the cache. This is the bookstore's case.
• Distributed databases and key-value stores: Amazon's Dynamo, Apache Cassandra and Riak place data on a ring with virtual nodes and replicate along it.
• Load balancers: "send requests for the same user or key to the same backend" with minimal disruption when backends change; Envoy offers ring-hash and Maglev load-balancing policies, and NGINX can hash upstreams consistently. Google's Maglev is a consistent-hashing load balancer built for even spread and fast lookups.
• CDNs and sharded storage: picking which cache server inside a PoP holds an object (Chapter 26).
• Partitioned stream processing and chat: keeping all messages for one conversation or user on one worker.

When not to use a ring: many systems use a fixed number of slots or partitions instead. Redis Cluster splits keys into 16,384 hash slots and assigns slots to nodes (Chapter 13); Kafka has a fixed number of partitions per topic (Chapter 22). Moving whole slots between nodes gives the same "only a small share moves" benefit with simpler bookkeeping. In an interview, both are good answers; explain the trade-off.

Memory code: "Wherever helpers come and go, seat the crowd at a round table."

---