Design YouTube Likes Counter

2B logged-in users. Average user likes ~5 videos/day. That's 10B likes/day ~ 115K writes/sec average, ~500K peak. Reads are heavier: every video page load fetches the like count. At 5B video views/day, that's ~58K count reads/sec, but most are served from cache. The dedup set is ~5 TB (300B entries at 16 bytes each over 30 days).

The dominant challenge is write volume. A single Cassandra row per video becomes a hot partition instantly. The entire design revolves around distributing writes across shards and reconciling periodically.

Two paths diverge from the API gateway:

• Write path: Like request → dedup check (Bloom filter + Redis SET) → publish to Kafka → counter aggregator consumes and increments sharded counters → periodic flush to Cassandra → cache invalidation in Redis.
• Read path: Stats request → Redis cache hit (most cases) → on miss, read from Cassandra counter table + rebuild cache. User's own like status read directly from dedup store.

Step 1 — Dedup check. Two-tier: Bloom filter (in-memory, ~1% FP) rejects obvious duplicates instantly. On "maybe," check Redis SET likes:{video_id}. False positive from Bloom = one extra Redis lookup. Prevents double-counting under retries.

Step 2 — Publish to Kafka. Publish LikeEvent{video_id, user_id, LIKE|UNLIKE} to a topic partitioned by video_id. Kafka provides durability and ordering. Partitioning ensures all likes for one video go to the same consumer.

Step 3 — Sharded in-memory aggregation. Each aggregator instance holds a local shard counter per video. 50 aggregators handling a viral video at 100K likes/sec = ~2K increments/sec each — trivial in memory.

Step 4 — Periodic flush to Cassandra. Every ~5s, flush accumulated deltas. Table: video_id, shard_id, count_delta. Total = SUM(shards). Turns 500K writes/sec into ~10K batch writes every 5s.

Step 5 — Cache invalidation. After flush, update Redis count:{video_id}. Reads hit cache (sub-ms); on miss, sum shards from Cassandra. Staleness: at most ~5s.

The unlike path mirrors the like path: dedup confirms user liked it, publishes decrement, aggregator subtracts.

sequenceDiagram
    participant C as Client
    participant API as API Gateway
    participant LS as Like Service
    participant BF as Bloom Filter
    participant RS as Redis (dedup SET)
    participant K as Kafka
    participant AG as Counter Aggregator
    participant CA as Cassandra
    participant RC as Redis (count cache)

    C->>API: POST /videos/{id}/like
    API->>LS: forward (auth validated)
    LS->>BF: check(user_id, video_id)
    BF-->>LS: maybe new
    LS->>RS: SISMEMBER likes:{vid} user_id
    RS-->>LS: 0 (not member)
    LS->>RS: SADD likes:{vid} user_id
    LS->>K: publish LikeEvent{vid, uid, LIKE}
    LS-->>C: 200 OK
    K->>AG: consume (partitioned by vid)
    AG->>AG: increment in-memory shard counter
    Note over AG: every ~5 seconds
    AG->>CA: batch flush shard deltas
    AG->>RC: SET count:{vid} new_total
    Note over RC: reads serve from here
          

1. Start with the write path, not the read path. The hard part is absorbing 500K writes/sec without hot rows. Most candidates jump to "use Redis INCR" — which works until you need durability, dedup, and crash recovery.
2. Name the sharded counter pattern explicitly. "I'll use N counter shards per video, flush deltas periodically" shows you understand distributed counting. This is the key insight the interviewer is looking for.
3. Don't forget dedup. A counter without dedup is a broken counter. Mention Bloom filter + authoritative store as a two-tier approach. Discuss the false-positive tradeoff.
4. Clarify consistency requirements early. "Is exact real-time count needed, or is ~5s eventual consistency OK?" This question shows maturity. YouTube shows approximate counts — that's a hint.
5. Kafka is the shock absorber. Explain why async is safe here: unlike a payment, a like being delayed by 5 seconds is invisible to the user. Kafka decouples the write spike from the DB capacity.