← Lessons

quiz vs the machine

Gold1400

System Design

Design a Distributed Counter

Count high volume events like likes accurately without a single write hotspot.

5 min read · core · beat Gold to climb

Requirements

  • Increment a counter under very high write rates.
  • Read the approximate or exact total quickly.
  • Avoid a single row becoming a write hotspot.

High level design

Spread writes across shards and sum on read.

  • Sharded counters: split one logical counter into n physical counters, each incremented by a random or hashed shard.
  • Read path: sum the n shards to get the total, optionally caching the result.
  • Local aggregation: each server buffers increments in memory and flushes batched deltas to its shard.

Bottlenecks

  • Single row contention: incrementing one row serializes all writes, so sharding removes the hotspot.
  • Read cost: summing many shards is more expensive, so cache the total and refresh periodically.
  • Exactness: for exact counts use durable atomic increments, for approximate counts buffer and flush.

Tradeoffs

  • More shards reduce write contention but make reads sum more values.
  • In memory buffering boosts throughput but risks losing recent increments on crash.

Key idea

A distributed counter shards one hot value into many to spread writes, then sums shards on read, trading read cost for write scalability.

Check yourself

Answer to earn rating on the learn ladder.

1. Why split one counter into many sharded counters?

2. What is the cost of sharding the counter?