Design a Distributed Counter

Counting sounds trivial. count += 1. But try doing it a million times per second across ten machines, and you will discover that counting is one of the hardest problems in distributed systems.

The core paradox: a counter is a single number, but no single machine can handle the write rate. You must split one value across many nodes. And the moment you do, no single node knows the real count. Every design decision in this editorial flows from that tension.

Functional

Traffic

Anchor to YouTube scale: 500 million videos, with the top videos receiving 100K+ views per second. Total across all videos: roughly 1 million increment operations per second. Most counters are cold (a few writes per hour), but a handful are extremely hot (viral content).

Storage: The Surprising Part

Read Counter

GET /counters/:entity_id

Response: { "count": 1523400, "last_updated": "2026-03-03T10:30:00Z", "approximate": true }

Redis: The Write Path

Redis is the primary write target. Every increment hits Redis first, and the database learns about it minutes later. This is write-behind caching: the inverse of the typical cache-aside pattern where you write to the database first and cache second.

Key Redis data structures for counters:

Architecture Overview

The system has two paths: a fast write path and a durable read path.

Increment Write Flow

1. Client sends PUT /counters/video_123 with X-Request-ID: abc-def and { "action": "increment" }.
2. API Gateway validates the request, rate-limits by client IP, and publishes the event to the increment-events Kafka topic. The entity_id (video_123) is the partition key, ensuring all increments for the same entity go to the same partition (preserving order).
3. Kafka durably stores the event. If the Kafka cluster has a replication factor of 3, the event is written to 3 brokers before acknowledging.
4. Count Server consumes the event from its assigned partition. It checks SET NX dedup:abc-def EX 60 in Redis. If the key already exists (duplicate), skip. If new, proceed.
5. Redis INCR counter:video_123, atomic, sub-millisecond. Redis returns the new value (e.g., 1524).
6. Acknowledgment: the count server commits the Kafka offset, confirming processing.

GATE: Sharded Counter Design

A single Redis key handles roughly 100K INCR operations per second. For most counters, this is more than enough. But when a video goes viral (500K views per second) a single key becomes the bottleneck.

The solution: split ONE counter into N sub-counters.

Eventual Consistency vs Strong Consistency

Strong consistency requires every increment to be synchronously written to PostgreSQL before acknowledging. This gives perfectly accurate reads but limits throughput: PostgreSQL handles roughly 5K write transactions per second on a single node. At 1M increments/sec, you would need 200 PostgreSQL instances, with each increment taking 5-20ms instead of sub-millisecond.

Eventual consistency with write-behind caching gives 100K+ writes per second per Redis instance at sub-millisecond latency. The cost: reads may be stale by up to one flush interval (60 seconds). For view counts, being off by a few hundred out of 1.5 million is invisible. For rate limiting, you would tighten the flush interval to 5-10 seconds or use synchronous Redis without the DB flush path.

Redis Primary Failure

When a Redis primary fails, all unflushed increments since the last flush are at risk. If the last flush was 45 seconds ago and the counter receives 100K INCR/sec, that is 4.5 million potentially lost increments.

HyperLogLog for Unique Visitor Counting

Standard counters count events (every view increments by 1). But what if you need unique visitors. The same user watching a video 10 times counts as 1? Storing every user ID in a set would consume enormous memory at scale. HyperLogLog solves this: PFADD unique:video_123 user_456 adds the user, PFCOUNT unique:video_123 returns the approximate unique count. Memory usage is fixed at roughly 12KB per counter, regardless of whether you have 1,000 or 1 billion unique visitors. Trade-off: roughly 0.81% standard error.

Time-Windowed Counters for Trending