Hot keys and hot partitions

When one key, such as a celebrity's profile, receives a large share of traffic, the partition or shard holding it saturates while others idle. Replicate hot keys, add a random suffix or cache them close to the app.

Where it shows up in real systems

  • Key-value store

    Data is spread across partitions by the hash of its key, so throughput scales almost without limit as long as keys are well distributed. A single very popular key hits one partition's limit and gets throttled. On-demand mode follows traffic but absorbs sudden jumps above twice the previous peak with throttling.

    In production: Amazon DynamoDB, Azure Cosmos DB, Google Bigtable, Riak, FoundationDB

  • In-memory cache

    The hit ratio depends on how much of the working set fits in memory, the TTL and the eviction policy. If the cache goes down or is flushed, every read falls on the database at once: plan for that stampede. Write-behind is fast but loses writes if a node dies without a replica.

    In production: Redis (Amazon ElastiCache, Azure Cache), Valkey, Memcached, Dragonfly

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox