Even key ownership does not mean even traffic#
normal profile → 10 RPS
celebrity profile → 100,000 RPSA distributed cache may spread millions of keys evenly, yet one celebrity key still belongs to a particular node and can exhaust its network, CPU, or request concurrency. The Consistent Hashing lesson limits key movement when nodes change; it does not split one key's popularity.
| Mitigation | What it changes | Trade-off |
|---|---|---|
| Local in-process copy | Removes repeated shared-cache reads | More stale copies to coordinate |
| Replicated copies | Spreads reads across cache nodes | Invalidation and replica consistency |
| Request coalescing | Bounds refresh work | Does not remove hit traffic |
| Split logical value | Distributes work where semantics permit | Read aggregation and key design |
| Edge cache / precompute | Moves reusable work outward | Only fits safe, cacheable content |
Detect hot keys with per-key or heavy-hitter telemetry, node load distribution, latency, and miss amplification - not only a cluster-wide hit rate.
- Assuming consistent hashing guarantees uniform request load.
- Scaling the entire cluster when one key is the bottleneck.
- Replicating correctness-sensitive values without a freshness plan.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Caching challenges and strategiesAmazon Builders' Library
Reach this point to mark the lesson as read.