A time-series table hashes writes on device_id, but one industrial sensor array alone generates 40% of all writes and keeps overloading its shard. What techniques let you avoid this single hot shard without abandoning hash sharding entirely?

## What a hotspot actually is A **hotspot** in a sharded system is a shard receiving disproportionate load relative to its siblings, and it's distinct from a **storage imbalance** — a shard can be perfectly average in total data size while still being overwhelmed on writes-per-second because one specific key on it is unusually active. Plain hash sharding maps a given key to exactly one shard deterministically: `hash(device_id) mod N` always returns the same shard number for that `device_id`, no matter how much traffic that device generates or how many total shards exist. If one device generates 40% of all writes, that 40% is permanently pinned to a single shard, and no amount of adding more shards to the cluster changes that, because the hash of that one unchanging key still resolves to one place. ## The techniques that actually move the load The fix has to change what value the hash function actually operates on, not how many shards exist. 1. **Composite key.** The most common technique is a composite key: instead of hashing `device_id` alone, hash on `(device_id, time_bucket)` — for example, `device_id` plus the current hour or day. Now the same device's data is spread across many distinct keys over time, each of which independently hashes to a (potentially different) shard, so the device's write volume gets distributed instead of concentrated. 2. **Key salting.** A second technique, key salting, is used when you can't naturally decompose the key by time or another dimension: you append a random or round-robin suffix (say, a digit 0–9) to the hot key before hashing, so writes for that one logical entity fan out across up to 10 shards. This works for any hot key, not just time-series ones, but it means reads for that entity must now query all salted variants and merge the results — you've traded a simple single-shard read for a scatter-gather read, in exchange for solving the write bottleneck. 3. **Directory-based isolation.** A third technique is directory-based isolation: rather than trying to force a known outlier entity through the general hashing scheme at all, you give it its own dedicated shard (or shards) via an explicit lookup mapping, sized and provisioned specifically for its load, while everything else continues through normal hashing. 4. **Reducing the raw write volume.** A fourth, complementary technique is reducing the raw write volume hitting the shard layer in the first place — buffering or pre-aggregating high-frequency writes (e.g., rolling 1-second sensor readings into 1-minute summaries) before they're persisted, so the shard sees fewer, larger writes instead of a flood of tiny ones. ## Why the problem exists at all The reason this class of problem exists at all is that real-world key distributions are almost never uniform — they tend to follow a **power law**, where a small number of entities (a viral post, a huge enterprise tenant, an industrial sensor array) generate vastly more activity than the median entity. A sharding scheme naively designed around "average" load per key will always be vulnerable to whichever entity turns out to be the extreme outlier, and outliers are usually impossible to predict at design time; they emerge from real usage. ## How it shows up in production Operationally, a hotspot shows up as one shard's latency, CPU, or throttling metrics diverging sharply from its siblings while the cluster-wide average looks fine — which is exactly why hotspots are dangerous: aggregate dashboards can hide them, and the team only notices once the hot shard starts rejecting or queuing writes. The failure mode compounds under **retry storms**: if writes to the hot shard start timing out, clients retrying those writes add even more load to the same already-struggling shard. ## Where it shows up by name This is a well-documented, named problem in managed sharded databases. - **AWS DynamoDB's** own documentation explicitly warns about "hot partitions" and recommends write sharding — appending a random suffix to a partition key for known high-traffic items — as the standard mitigation. - **Twitter's** engineering blog has historically discussed the analogous "celebrity problem," where a small number of accounts with enormous follower counts or posting volume require special-cased handling distinct from the sharding scheme that works fine for typical users. In both cases, the lesson is the same: hash sharding solves even distribution for a typical key distribution, but any system expecting a skewed, power-law distribution of activity needs an explicit strategy — salting, composite keys, or dedicated isolation — layered on top of the base hashing scheme to handle its outliers.