Consistent Hashing
Virtual nodes, ring topology, and minimal key remapping during server additions and failures.
Write:Read ratio 1:10P99 Latency < 100ms- “In Project44, we handled this scale by isolating writes with partition keys and caching hot reads.”
- “I would start with Consistent Hashing to guarantee high availability while keeping complexity minimal.”
TOPIC: Consistent Hashing
1. Meaning
Consistent hashing distributes keys across servers so adding or removing servers moves only a small portion of keys, not almost everything.
Analogy: Circular clock with servers placed at positions. Each key goes clockwise to next server.
Project44 example: If you partition alert-processing state or cached tracking data across multiple servers, consistent hashing can reduce reassignment when servers change.
2. How it works
Step 1 — Build hash ring
Hash each server ID → position on virtual circle.
Step 2 — Hash each key
Hash key → position on same ring → move clockwise to first server.
Step 3 — Handle server changes
Add server → only keys in its ring segment move. Remove server → its keys move to next server.
Virtual nodes (vnodes)
One physical server gets multiple positions on ring.
Why? Three servers with one position each can create uneven load. Hundreds of virtual positions per server usually improve distribution.
Vnodes improve balance, but cannot guarantee equal load when key traffic is skewed.
3. AWS service + what changes on AWS
| Layer | Generic concept | AWS option |
|---|---|---|
| Key routing | Hash ring in app | Amazon ElastiCache for Redis/Valkey with client-side hashing |
| Distributed cache | Keys spread across nodes | Amazon ElastiCache for Redis/Valkey cluster mode |
| Distributed DB | Partition keys across nodes | Amazon DynamoDB partition-key-based distribution |
| Event stream | Partition events across workers | Amazon Kinesis Data Streams shards |
Important: These are not interchangeable. DynamoDB manages partitioning internally; Kinesis routes records by partition key to shards. Neither requires you to implement your own hash ring.
AWS tradeoff: Managed services reduce ops work and simplify scaling, but add service costs, quotas, configuration limits, and AWS lock-in. I would not introduce a custom hash ring unless I controlled routing and needed that flexibility.
4. Tradeoffs
- Consistent hashing vs modulo hashing:
hash(key) % Nis simple, but changingNcan remap most keys. Choose consistent hashing when nodes change often. - Consistent hashing vs range partitioning: Hashing distributes keys well; range partitioning supports range queries better but risks hot ranges.
- One position vs vnodes: One position is simpler; vnodes improve balance at cost of more metadata and routing complexity.
- Custom ring vs managed DB: Custom ring gives control but requires membership management, retries, rebalancing, and failure handling. Choose managed DB when its partitioning model fits.
5. Alternatives compared
| Approach | Best for | Main drawback |
|---|---|---|
| Modulo hashing | Fixed server count | Massive remapping after changes |
| Consistent hashing | Dynamic server pool | Ring and membership complexity |
| Rendezvous hashing | Simple node scoring | Scores computed across candidate nodes |
| Range partitioning | Ordered/range queries | Hot ranges possible |
| Managed partitioning | Operational simplicity | Less control over placement |
Decision rule: Dynamic cache/server pool → consistent hashing. Fixed pool → modulo may suffice. Ordered queries → range partitioning. Managed AWS DB → use native partitioning first.
6. Example from your projects
Bulk Tracking Search: You used Elasticsearch terms queries for bulk tracking lookup. That is not the same as implementing consistent hashing.
If designing a custom distributed cache for tracking results:
- Hash tracking ID.
- Route key to owning cache node.
- Add node → move only affected keys.
- Cache miss → fetch from authoritative DB/service.
- Replicate or reconstruct cache entries after node failure.
For production, I'd first evaluate ElastiCache rather than build custom routing.
7. Interview Qs + answers
Q1. Why is consistent hashing better than modulo hashing?
Modulo can remap most keys when server count changes. Consistent hashing limits remapping to affected ring segments.
Q2. What are virtual nodes?
Multiple ring positions per physical server. They improve distribution and reduce imbalance.
Q3. Does consistent hashing guarantee equal load?
No. Uneven key popularity can create hot keys even with balanced key distribution.
Q4. What happens when a node fails?
Its keys route to successor nodes. Replicas or backing storage must provide data; hashing alone does not preserve data.
Q5. How do you add a node safely?
Update membership consistently, move affected data if needed, handle in-flight requests, and monitor load during rebalancing.
Q6. How do you handle hot keys?
Cache replication, request coalescing, local caching, or splitting hot-key workloads. Adding nodes alone may not help.
Q7. Is consistent hashing a DB sharding strategy?
It can be one. Sharding also requires data migration, replication, query routing, and failure recovery.
Q8. Does DynamoDB use my custom hash ring?
No. DynamoDB manages physical partition placement internally based on partition keys and service behavior.
8. One-sentence interview answer
“Consistent hashing maps servers and keys onto a logical ring, routing each key to the next server clockwise, so node changes remap only a fraction of keys instead of most of the dataset.”
9. Memory trick
Ring → Hash → Clockwise → Vnodes → Minimal remapping
Remember: consistent hashing reduces movement, not necessarily load imbalance.