📝 Problem Description
Design a system to count and display likes for posts at Facebook scale. Handle billions of posts, millions of likes per second, and display accurate counts. This problem explores the classic "hot key" challenge in distributed systems and introduces sharded counters as a solution. Focus on write scalability, read efficiency, and the tradeoffs between consistency and performance.
👤 Use Cases
1.
User wants to likes a post so that like count increments and UI shows liked state
2.
User wants to views a post so that sees current like count formatted (e.g., "1.2M")
3.
User wants to unlikes a post so that like count decrements and UI shows unliked state
4.
User wants to views who liked so that sees paginated list of likers (friends first)
5.
User wants to double-taps on mobile so that like is registered with animation feedback
6.
Celebrity wants to posts viral content so that system handles millions of likes without degradation
7.
System wants to reconciles counts so that counter matches actual likes in source of truth
8.
Admin wants to views analytics so that sees like velocity and trending posts
✅ Functional Requirements
- •Like/unlike posts with immediate UI feedback
- •Display like count on posts (exact or approximate)
- •Show if current user liked the post
- •List users who liked (paginated, friends prioritized)
- •Prevent duplicate likes per user per post
- •Support multiple reaction types (like, love, haha, etc.)
- •Show like velocity for trending detection
- •Provide analytics on likes over time
⚡ Non-Functional Requirements
- •Handle 1M+ likes/sec during viral events
- •Like action < 100ms latency (user-facing)
- •Count display < 50ms latency
- •Support billions of posts
- •Eventual consistency acceptable (< 5 second lag)
- •99.99% availability for like operations
- •Zero duplicate likes even under race conditions
⚠️ Constraints & Assumptions
- •Cannot update single counter on every like (hot key problem)
- •Must prevent duplicate likes per user per post
- •Exact count not required for very large numbers (show "1.2M" not "1,234,567")
- •Unlike must succeed even if original like is not found in cache
- •Counter must never go negative
- •Counts should be recoverable from source of truth (likes table)
- •Must handle celebrity posts with millions of likes/hour
📊 Capacity Estimation
👥 Users
2B users, 100M DAU
💾 Storage
15TB (likes data + indices)
⚡ QPS
Writes: 1M/sec peak, Reads: 10M/sec peak
📐 Assumptions
- • 2B registered users
- • 100M daily active users
- • 100B posts total
- • Average 50 likes per post
- • 5 trillion total likes
- • 1M likes per second during peak (viral events)
- • 10:1 read to write ratio on counts
- • Average like record: 50 bytes
💡 Key Concepts
CRITICAL
Sharded Counters
Split a single counter across N shards (e.g., 100) to distribute writes. Write to random shard, read by summing all shards. Avoids hot key problem where one Redis key receives millions of updates/sec.
HIGH
Async Counting
Counter updates happen asynchronously via Kafka. The like operation returns immediately without waiting for counter update. This provides eventual consistency with high availability.
HIGH
Bloom Filter
Space-efficient probabilistic data structure for "has user liked this post" checks. Returns "definitely not liked" or "possibly liked". 99% of checks are "not liked" so this saves most DB reads.
MEDIUM
Approximate Display
Show "1.2M" instead of exact count for large numbers. Users don't care about exact count for popular posts. Allows for eventual consistency without confusing users.
MEDIUM
Counter Reconciliation
Daily job that compares Redis counters with actual Cassandra counts and fixes drift. Ensures counters stay accurate despite lost events or failures.
MEDIUM
Optimistic UI
Show the like/unlike state immediately before server confirms. If server fails, revert the UI. Provides instant feedback for better UX.
💡 Interview Tips
- 💡Start by explaining the hot key problem - single counter can't handle 1M writes/sec
- 💡Introduce sharded counters as the core solution - this shows distributed systems knowledge
- 💡Discuss the sync write (Cassandra) + async count update (Kafka) architecture
- 💡Explain why eventual consistency is acceptable for like counts
- 💡Mention Bloom filter optimization for "has user liked" checks
- 💡Be ready to discuss counter reconciliation and drift correction
- 💡Know the numbers: 1M writes/sec, 10M reads/sec, 100 shards, 5s cache TTL
- 💡Discuss the tradeoff between accuracy and scalability