High-Level Design of Sharded Counters

High-level solution sketch

Handling millions of likes on a single tweet can create contention on a shared counter. If each like generates a write request to the same counter, the updates are serialized at that resource. This serialization increases write latency and limits overall throughput.

If a counter’s update latency misses its target, first identify whether the hot key is the limiting resource. Sharding is one way to distribute that work.

The following illustration demonstrates this problem:

A sharded counter stores several partial counts and routes each accepted update to one shard. Shards can run on different nodes, though several may share a node. Atomic updates are still required within each shard. Spreading writes reduces pressure on any one counter key.