0% completed
YouTube Likes Counter: Requirements
On This Page
Step 2: Clarify and Define Requirements
Functional Requirements
Non-Functional Requirements
Step 2: Clarify and Define Requirements
Functional Requirements
Functional requirements say what the system must do. We agree on this list before we design anything. There are five, listed in the diagram below.
- Like and dislike. A user can like or dislike a video or a comment. Each valid action updates the total count for that item. A user holds one reaction state per item: Like, Dislike, or None.
- Undo and toggle. A user can undo a reaction, which sets it back to None. A user can also toggle it, for example from Like to Dislike. A toggle changes two counts at once: the old count goes down by one, and the new count goes up by one.
- Idempotency. An operation is idempotent when doing it twice has the same effect as doing it once. Network retries can deliver the same like or dislike event more than once. Processing it again must not raise the count or corrupt the data.
- Reading counts and state. The system must return the total likes and dislikes for a video or comment. It must also return the user's own current state, for example "isLiked: true". The client needs both on every page load to draw the buttons.
- Read-your-own-writes. The user who clicked must see the change at once. The global count that other users see may take a few moments to update. If the count does not move for the user who clicked, the click looks like it failed.
Two items on this list, idempotency and read-your-own-writes, are promises rather than features. Much of the design ahead exists to keep them true at scale.
Non-Functional Requirements
Non-functional requirements say how well the system must do those things. They are what make this design hard: a correct counter is easy, and one at this scale is not. There are five, shown below.
Scalability. The system must accept billions of reaction events and serve a very high rate of reads. No single machine can do that, so the system must grow by adding machines (horizontal scaling).
We also split the data across those machines (sharding). Growth in users and content then never depends on one server.
Performance. A write, that is one reaction, should ideally finish in under 100 ms at p95. Here p95 means that 95 out of every 100 requests finish within that time. A read of the counts should ideally finish in under 20 ms.
The read target is tighter because a count is fetched on every video and comment view, while writes happen far less often. Read latency is what almost every user experiences. We choose high throughput and low latency over immediate global consistency.
Consistency model. We accept eventual consistency for the total counts. Eventual consistency means replicas and caches may briefly show an older number than the main copy. Given enough time, every node reaches the same correct count.
Strong consistency is not needed for a popularity number. Accepting a short delay is what lets a write finish without waiting for every replica to agree.
Availability and reliability (CAP theorem). A network partition is when some machines cannot reach others. The CAP theorem says that during a partition a system must choose between staying available and staying consistent. We choose availability (AP).
A count that is a few seconds old is still useful to a viewer. So when a fresh count is not available, the system serves a slightly old count instead of an error. It keeps serving during partitions and node failures.
We also copy data to more than one machine (replication), so a failure does not lose data.
Durability. The system may buffer writes in memory to handle bursts. Memory does not survive a crash, so buffering alone is not enough. The final state must still reach durable storage, that is storage that survives a crash.
No reaction is lost once the system has acknowledged it.
Next: Step 3, where those requirements become numbers.
Reading Progress
0%
On This Page
Step 2: Clarify and Define Requirements
Functional Requirements
Non-Functional Requirements