How do you build a real-time view/like counter for viral posts?

Question

IT Interview Practice · Accepted Answer

Never `UPDATE posts SET views = views + 1` per event on a hot post — that one row becomes a lock bottleneck. **Increment in Redis, batch-flush to the DB** every few seconds, and read the count from Redis. The DB stores durable totals, not live traffic.

## Architecture

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## Components and flow

- **Redis INCR** absorbs the write storm. A single `INCR views:{post}` is atomic and handles 100k+ ops/s on one key — orders of magnitude past a Postgres row. This counter is the source of truth for *reads*, so viewers see the number move instantly.
- **Dedup for likes/unique views**: a raw counter double-counts refreshes. Use `SADD seen:{post} {userId}` and only `INCR` when the add is new; for cheap approximate uniques at massive scale use **HyperLogLog** (`PFADD`/`PFCOUNT`) — a few KB estimates millions of uniques within ~2% error.
- **Batched flusher** periodically drains the delta to the DB: `UPDATE posts SET views = views + delta`. Flushing every 5s or every N increments turns a million writes into a handful — the DB holds the durable total for cold posts and analytics.
- **Read path** serves from Redis; on a cache miss it reads the DB total and re-warms Redis. Likes need per-user state (did *I* like it), so store the set, not just a number.

## Interview perspective

Interviewers test whether you accept **eventual consistency for counts**. "Good" is "cache the count"; "great" is buffering *writes* — recognizing the bottleneck is write contention on a hot row, not read load. They probe the trade: is an approximate count acceptable? For view counts, yes — nobody notices 1,203,428 vs 1,203,450. The trap is worrying about exact counts and reaching for a transaction, reintroducing the lock you were avoiding.

## Trade-offs and failure

- **Accuracy vs throughput**: exact counts need dedup sets (memory-heavy); approximate HyperLogLog is tiny and fast. Pick per feature — likes are exact, view counts can be approximate.
- **Durability**: Redis is in-memory. If it dies before a flush, you lose the un-flushed delta. Enable AOF and keep flush windows short (seconds) to bound the loss; the DB total plus a small gap is acceptable for a view counter.
- **Hot key**: a viral post concentrates all traffic on one Redis key. Shard it into `views:{post}:{0..9}` and sum on read, or route hot keys to a dedicated node so one post can't saturate the shard.

Architecture

Components and flow

Interview perspective

Trade-offs and failure

Related questions