The same ring, different uniforms
Once you know the shape, you start finding the ring everywhere, wearing different uniforms.
Distributed caches were the first customer, and probably where you will meet it. A scheme called ketama brought consistent hashing to cache clients in 2007, so fleets could be resized without emptying themselves. Every serious client library offers an equivalent mode now.
Choose it deliberately when a cache client asks you for a hashing strategy. Ring hashing is the answer that makes changing the node count survivable.
Dynamo-style databases put the ring at the centre of their design. Amazon's paper used it with virtual nodes to divide up the keys, and replication rides on the same structure. A key's copies are simply the next few distinct servers walking clockwise, so placement and redundancy come out of one idea. Cassandra inherited the token ring directly, and several stores you may already run descend from that same paper.
It traces back to CDNs, where it was born. The 1997 paper that introduced consistent hashing was about caching web objects across a pool of servers that kept changing, and a company was founded to commercialise it. When an edge location maps a URL to one of its cache servers today, a ring or a close relative decides.
It turns up in load balancers, where it buys stickiness without storing anything. Hash a user's session and walk the ring. That user lands on the same backend every time while backends come and go, which keeps their cache warm with no session table anywhere.
The trigger in interviews is one of three phrases: shard a cache, partition by key across a pool that changes size, or move as little as possible when we scale out. Say consistent hashing, mention virtual nodes for spreading load, and give the movement number. Those three beats cover what most interviewers are waiting to hear.
Worked example
Rafael's team runs a WebSocket gateway for a trading app: 40 pods, each holding per-user order-book subscriptions in memory. They balance connections round-robin, so every reconnect lands on a random pod that must rebuild the user's subscription state from scratch, about 900 ms of backend fetches per reconnect, and deploys trigger reconnect storms that hammer the subscription service. He switches Envoy to ring-hash balancing on user ID. Now a reconnecting user lands on the pod that already holds their state, rebuild happens only when that specific pod is gone, and during a rolling deploy of 40 pods, each pod's users redistribute in small slices instead of all at once. Reconnect cost drops to 80 ms for the 97 percent of users whose pod survived, and the subscription service's deploy-time load spike shrinks by a factor of 12.