Distributed Counting: A Pattern for Counting at Scale
Practice this topic in a realistic system design interview
Counting looks simple when one database row can handle the write rate: increment a number when something happens and show the latest value.
At scale, the hard part is not addition. The hard part is keeping the write path fast when one logical counter becomes a hot key, while still handling retries, duplicate events, stale reads, and recovery after failures.
This problem appears in many large-scale systems. YouTube counts video views. Twitter counts likes and retweets. Reddit counts upvotes. Instagram counts followers. Commerce systems count available inventory, though inventory usually needs a reservation or ledger model rather than a simple eventually consistent counter.
Every high-scale system eventually faces the same question: how do you count reliably when many events hit the same logical item at the same time?
The challenge is choosing the right point in the trade-off space: exact vs approximate, immediate vs delayed, cheap reads vs cheap writes.
A strong interview answer starts by clarifying the required accuracy, freshness, write rate, and retry behavior. Those requirements determine whether a single counter, sharded counter, async aggregation pipeline, or approximate data structure is appropriate.
Interview Answer Shape
In an interview, do not start with a sketch or a queue. Start with the counter's correctness contract:
- Clarify whether the count must be exact, approximate, immediately visible, or allowed to lag.
- Identify the hot key: one logical counter can overload one row, shard, or partition.
- For moderate write rates, use atomic database increments or conditional updates.
- For hot exact counters, shard the counter and cache aggregated totals.
- For very high throughput with stale reads allowed, write events to a durable log and aggregate asynchronously. Always mention idempotency, replay, and reconciliation.