Step 5: High-Level Design

The system has two jobs: record each Like or Dislike click, and show the totals when someone opens a video. We follow one example of each: Alice likes video XYZ1, and a moment later Bob opens the same video. The diagram at the end of this lesson shows both paths.

The write path: Alice likes a video

1. Alice's app sends the click to the API gateway. The gateway checks that she is signed in, limits how many requests one address can send, and passes the request to one of many identical copies of the Like/Dislike Service. The service keeps no data between requests (it is stateless), so any copy can handle any request, and adding copies handles more traffic.
2. The service works out what changes. It looks up Alice's current reaction to XYZ1. If she had none, likes go up by one. If she had already liked it, nothing changes. If she had disliked it, dislikes go down by one and likes go up by one.
3. The service writes two things. It saves Alice's new reaction in the user-actions table and records the change to the totals of XYZ1 in the counts store.

The user-actions table has one row per user per item, like "Alice likes XYZ1". Every write is an upsert: it inserts the row if it is missing and overwrites it if it exists. Alice can never have two rows for XYZ1, so this row stops her from liking it twice.

The read path: Bob opens the video

Bob's app asks for the totals of XYZ1 and its comments, plus his own reaction to each, so it can show which buttons he has pressed. The service never counts rows in the user-actions table to answer, because a popular video has millions of them. It reads the totals already stored in the counts store, one row per item.

The two stores

The two stores hold the same clicks in two shapes. One row per user per item keeps the data correct, and one row per item keeps reads fast.

User actions live in a distributed NoSQL database like Cassandra or DynamoDB. The table grows by billions of rows a month, and Cassandra takes heavy writes and grows by adding machines, with no single leader. Each region keeps a copy and accepts writes, so no user waits for a distant data center.

Counts live in two places. Redis, an in-memory cache, answers every count read, because only memory can serve 250,000 reads a second within 20 ms at a sensible cost. A NoSQL table, ContentStats, keeps the durable copy that Redis reloads from when it loses a count.