Why one row does not scale
A single counter row updated by millions of writers becomes a hot spot: every increment contends on the same lock. Throughput collapses well before the data is large.
Sharded counters
Split the counter into N shards, each a separate row. Each writer increments a random shard, spreading contention. The true total is the sum of all shards, computed at read time.
- Writes scale roughly N times because contention is divided.
- Reads cost more since they must fan out and sum N shards.
- Pick N to balance write throughput against read cost.
Approximate alternatives
When exact counts are not required, probabilistic structures like HyperLogLog estimate cardinality in tiny space, trading a small error for huge memory savings.
Key idea
A distributed counter shards a hot count into N rows so writes spread out, paying a higher read cost to sum shards, or uses probabilistic estimates when approximate counts suffice.