YouTube Likes Counter: Requirements

• Reaction Management (Like/Dislike): Users must be able to like or dislike videos and comments. Each valid action must update the aggregate count for that content entity. A user is limited to one active reaction state per item (Like, Dislike, or None).
• State Transitions (Undo/Toggle): The system must support mutability. Users can undo a reaction (reverting to "None") or toggle their state (switching from Like to Dislike). A toggle action implies two simultaneous count updates: decrementing the old reaction count and incrementing the new one.
• Idempotency: The system must handle duplicate requests gracefully. Repeated processing of the same like/dislike event (e.g., due to network retries) must not erroneously inflate counts or corrupt data.
• Data Retrieval: The system requires an interface to fetch aggregate counts (total likes/dislikes) and the user's current status (e.g., "isLiked: true") for a given video or comment. This data is critical for rendering the UI on every page load.
• Read-Your-Own-Writes Consistency: To ensure a positive user experience, the system must provide immediate feedback to the actor. When a user likes a video, their UI should reflect the change instantly, even if the global count visible to other users takes a few moments to converge.

Non-Functional Requirements

• Scalability: The system must be designed for web-scale traffic, capable of ingesting billions of reaction events and serving high-throughput read queries. The architecture should support horizontal scaling (sharding) to accommodate exponential growth in users and content volume.

• Performance:

  • Write Latency: Reaction processing should be rapid (ideally <100ms at p95) to ensure a responsive UI.
  • Read Latency: Fetching counts must be extremely fast (ideally <20ms) as this occurs on every video/comment view.
  • Trade-off: We prioritize high throughput and low latency over immediate global consistency.

• Consistency Model: We accept Eventual Consistency for aggregate counts. It is acceptable if replicas or caches lag slightly behind the master data. The system guarantees that given enough time, all nodes will converge to the correct count. Strong consistency is not required for popularity metrics.

• Availability & Reliability (CAP Theorem): In terms of the CAP theorem, this system favors Availability (AP) over Consistency. The service must remain operational even during network partitions or node failures. The design should utilize data replication to prevent data loss and support graceful degradation (e.g., serving slightly stale counts rather than returning errors).

• Durability: While the system may use in-memory caching for write buffering to handle bursts, the final state must eventually be persisted to durable storage. No user reaction should be lost once acknowledged by the system.