YouTube Likes Counter: High-Level Design

Step 5: High-Level Design

The system comprises multiple decoupled components designed to handle high concurrency, data persistence, and background processing. Below is an overview of the architecture and data flow:

• Clients (Web/Mobile): Users on YouTube's website or app. When a user clicks like/dislike on a video or comment, the client sends a write request to the backend. When viewing a video or a comment, the client requests the current like/dislike counts (and whether the user liked it).

• API Gateway / Load Balancer: Routes requests from clients to the appropriate service cluster. It can also perform coarse rate limiting (e.g., block a single IP making too many requests) and handle auth (ensuring the user is logged in).

• Like/Dislike Service (Microservice): This is the core application service that exposes endpoints for liking, disliking, and retrieving counts. There will be many instances of this service running (to handle massive concurrency). Key responsibilities:

  • Write API Handling: On a like/dislike request, authenticate the user, then process the like/dislike logic (e.g., ensure they haven't already liked it, handle toggling). It then records the event in a database. It will record two things: 1) User's actions like "Adam liked <content_id>", 2) Increment the like/dislike count of the content.
  • Read API Handling: On a get count request, fetch the current like and dislike counts for the requested item (video or comment), possibly from a cache or database. Also determine the requesting user's own reaction (to highlight the UI if needed).
  • This service is stateless (it doesn't keep data in process between requests), so it can be scaled horizontally and be resilient (one instance fails, others handle traffic).

• Database for Likes/Dislikes (user-action DB): A write-optimized database that stores the latest state of each user's like/dislike per video or comment. This will be a NoSQL distributed database (like Apache Cassandra or DynamoDB). The write is an upsert (i.e., update or insert) that either creates a new like/dislike record or updates an existing one (e.g., if the user toggled from like to dislike). The record is what lets the service tell a new reaction from a repeated one, because it holds the reaction the user already has. Doing that check correctly while two requests run at the same time is its own problem, and Step 8 solves it. We choose NoSQL for its scalability and high throughput on writes/reads. For example, Cassandra is designed to scale to very large sizes across many servers with no single point of failure, and is optimized for high write throughput (Facebook used it to handle billions of writes per day). For high availability, this database is distributed and replicated across regions (e.g., using a multi-master or leaderless DB like Cassandra or DynamoDB, which are designed for eventual consistency across data centers). Each write is local to the region (fast and available) and replicates in the background to other regions. This ensures even if one region's database goes down, the data exists elsewhere.

• Counts Store (Aggregated Counts): Two stores hold the same numbers for different reasons, and the rest of this case study uses both names. Redis serves every count read, keyed by content ID, because 250,000 reads per second cannot be sent to a database. ContentStats, a NoSQL table, holds the durable copy. Redis is refilled from it after a cache miss or a node failure, and the recount job in Step 10 corrects it. Redis is the read path; ContentStats is the record.

Next: Step 6, which defines the two tables this design needs.