Consistent Hashing in Practice

The hash ring that lets you add cache nodes without remapping every key.

Intermediate10 min read

Read these first

Partitioning and Sharding

Why this matters

VaultCommerce expanded its Redis cluster from 4 to 8 nodes during Diwali traffic; consistent hashing kept cache hit ratio above 85% through the rollout.
Shard rebalancing without consistent hashing causes overnight cache miss storms and database overload.
Interviews ask you to explain the ring, virtual nodes, and why hash tags matter in Redis Cluster.

The modulo hashing problem

Java

3 cache nodes, key "cart:user_42"
  slot = hash("cart:user_42") % 3  →  node 1

Add a 4th node:
  slot = hash("cart:user_42") % 4  →  node 2   ← MOVED

When most keys remap, VaultCommerce's product API would hammer Postgres until caches refill — a cache stampede visible to shoppers as 3-second page loads.

The hash ring

Node A0°–120°

Node B120°–240°

Node C240°–360°

Key Klands on B

Keys hash onto a ring. Adding a node only remaps its neighbours' keys.

Ring mechanics

Hash space forms a fixed ring (0 to 2³²−1).
Each node occupies one or more positions (virtual nodes).
Each key hashes to a position on the ring.
Walk clockwise from the key — the first node encountered owns it.
Adding a node steals only keys between its predecessor and itself (~1/N keys).

Only keys in the affected arc migrate. The rest stay put — preserving warmth in the cache.

Virtual nodes for even distribution

Physical machines map to multiple ring positions:

Java

Physical redis-1 → vnodes: r1-a, r1-b, r1-c, r1-d
Physical redis-2 → vnodes: r2-a, r2-b, r2-c, r2-d

Without virtual nodes, uneven key density leaves some machines underloaded. Redis Cluster, DynamoDB, and Cassandra all use vnode-style partitioning internally.

Redis Cluster hash tags

Multi-key operations require keys on the same slot. Redis supports hash tags — only the substring in {...} participates in slot calculation:

Java

SET cart:{user_42}:items "[{\"sku\":\"VC-HP-BLK\",\"qty\":1}]"
SET cart:{user_42}:coupon "DIWALI10"
GET cart:{user_42}:items

VaultCommerce wraps user_id in braces so cart items and coupons land on one slot — enabling atomic MULTI/EXEC without cross-slot errors.

Rebalancing in production

Event	Keys affected	VaultCommerce mitigation
Add node	~1/(N+1) of keys	Rolling add; monitor miss rate
Remove node	Keys owned by removed node	Drain node before removal
Hot key	One slot overloaded	Local cache + key replication
Shard migration	Arc between old and new owner	Dual-read during handoff

Add node
Keys affected~1/(N+1) of keys
VaultCommerce mitigationRolling add; monitor miss rate
Remove node
Keys affectedKeys owned by removed node
VaultCommerce mitigationDrain node before removal
Hot key
Keys affectedOne slot overloaded
VaultCommerce mitigationLocal cache + key replication
Shard migration
Keys affectedArc between old and new owner
VaultCommerce mitigationDual-read during handoff

Java

# Rolling Redis cluster expansion playbook
steps:
  - add_new_master_with_empty_slots
  - wait_for_key_migration_background
  - verify_hit_ratio > 80% for 15m
  - add_replica_per_new_master
  - update_client_slot_map

Quick recall

Everything you need if you only revisit this box.

Modulo hashing remaps most keys when N changes; consistent hashing remaps ~1/N.
Keys and nodes sit on a ring; walk clockwise to find the owner.
Virtual nodes spread load evenly across physical machines.
Redis {tag} syntax co-locates related keys for atomic multi-key ops.
VaultCommerce uses consistent hashing for Redis Cluster and order shard routing.

Test yourself

Answer these before moving on — recall is what makes it stick.