Picture a social app with four cache nodes in front of its user-profile database. Every profile key, like "user:48213", has to live on exactly one of those nodes, and every app server has to agree on which one. Traffic grows, so you add a fifth node. The question that matters is simple: how many keys suddenly point somewhere new?

If the answer is "most of them," every one of those lookups misses and lands on the database at the same moment. Consistent hashing is a way to map keys to nodes so that adding or removing one of N nodes moves only about 1/N of the keys.

In an interview, this comes up in the deep-dive stage of almost any design that spreads data or traffic across machines. The interviewer asks "how do you pick the node for a key?" and then "what happens when you add a server?" It is rarely the whole interview. Three to seven crisp minutes is the target.

How deep you need to go depends on the level. At mid-level, explaining why hash(key) % N breaks, drawing the ring, and saying "virtual nodes for balance" is usually enough. At senior level, expect follow-ups on picking replicas from the ring, choosing a virtual-node count, and when rendezvous or jump hashing is the better function. This tutorial covers all of that, and it stops at the function itself: the systems that call it are named only to show where the function sits.