Handling Write Hotspots with Sharded Counters, Key Salting, and Write Bucketing

Write hotspots are more challenging than read hotspots because writes typically require coordination for correctness (maintaining counters, enforcing uniqueness, preserving order). A single hot key receiving thousands of writes per second can saturate a database shard, cause lock contention, or exhaust write capacity even when the overall system has spare throughput. The primary mitigation techniques are sharded counters to distribute increment operations across multiple keys, key salting or hash prefixing to spread writes for a logical entity across multiple partitions, and write bucketing or batching to amortize overhead and reduce per operation cost. Sharded counters are the canonical solution for high throughput increment workloads like view counts, like counts, or metrics. Instead of incrementing a single counter key that might saturate at 1,000 to 10,000 writes per second depending on the backend, you create N counter shards (for example, 20 shards) and randomly distribute increments across them. Each shard receives roughly 1/N of the write load, so 20 shards can sustain roughly 20 times the throughput of a single counter. Reads aggregate by summing all shards, which adds read amplification but is acceptable when writes vastly outnumber reads. For example, if your backend sustains 10,000 writes per second per partition, using 20 shards yields approximately 200,000 increments per second. Background compaction can periodically fold shards to limit read amplification, and you can adjust the shard count dynamically based on observed load. Key salting or hash prefixing works by appending a salt or hash suffix to keys to distribute a hot logical entity across multiple physical partitions. For instance, if user:12345 is a hot key, you might create user:12345:0, user:12345:1, through user:12345:N and write to a randomly chosen suffix. Reads must aggregate across all suffixes. The trade off is that this breaks natural key ordering and makes range queries expensive or impossible. Use salting when random access dominates and hotspots are likely; avoid it when range scans or locality are critical. In DynamoDB, if a single item needs 5,000 RCU but partitions support roughly 3,000 RCU each, splitting across two salted keys keeps each under the per partition limit. Write bucketing combines batching with temporal or spatial grouping: buffer writes in memory for a short window (for example, 100 milliseconds to 1 second), batch them into a single backend operation to amortize overhead, and apply idempotency tokens to survive retries.

Reddit vote counters use sharded counters with 50 shards per post; each shard sustains 2,000 writes/s, yielding 100,000 votes/s per post; reads sum all shards and cache the result for 2 seconds

Google Cloud Bigtable for time series metrics salts row keys by hashing entity ID and appending timestamp; writes spread across tablets, avoiding hotspots from monotonic timestamps that would concentrate on one tablet

An e-commerce site batches inventory decrement operations over 500 millisecond windows, reducing DynamoDB write operations by 80% during flash sales while maintaining exactly once semantics via idempotency tokens