0% completed
Step 2: Requirements
On This Page
Functional Requirements
Non-Functional Requirements
Functional Requirements
An interviewer who asks for "the like button" has left most of the problem unstated. Can a user take a like back? Do comments count the same way as videos? Must the person who clicked see the new number immediately? The answers give the five functional requirements below. The first three cover the write path, and the last two cover the read path.
- Like and dislike. A user can like or dislike a video or a comment, and holds exactly one state per item: Like, Dislike, or None.
- Undo and toggle. A user can undo a reaction back to None or switch it from Like to Dislike. A switch moves two totals in one action, one down and one up.
- Idempotency. An operation is idempotent when doing it twice has the same effect as doing it once. Networks retry, so the same like can arrive twice, and the second must not raise the count.
- Reading counts and state. The system returns an item's like and dislike totals with the reader's own state, for example
"user_state": "like", which the client needs to draw the buttons. - Read-your-own-writes. The person who clicked must see the change immediately, while others may see it a few seconds late. A count that does not move after a click looks like a broken button, and users click again.
Idempotency and read-your-own-writes are guarantees rather than features. Without idempotency, the totals drift upward every time a mobile connection drops a response. Much of the later design exists to keep these two promises at scale.
Non-Functional Requirements
The functional list would fit a weekend project. The five non-functional requirements are what make this a distributed system.
Scalability. The system handles billions of reaction events and far more reads. Capacity grows by adding machines (horizontal scaling) and splitting the data across them (sharding), so growth never depends on one server.
Performance. A write should finish in under 100 ms at p95 (95 of every 100 requests finish within that time). A read of the counts should finish in under 20 ms. The read target is five times tighter because every page view fetches a count, while few viewers ever click.
Consistency model. The totals are eventually consistent: replicas and caches may briefly show an older number, but every copy reaches the same value within seconds once changes stop. Strong consistency would make each write wait until every replica agreed, and a popularity number does not justify that wait. Viewers already accept this: YouTube's view counter once stopped at about 300 on new videos while the system checked that the views were real.
Availability (CAP theorem). A network partition occurs when some machines cannot reach others. The CAP theorem states that during a partition, a system must choose between answering every request and guaranteeing that every answer is current. This system chooses availability (AP), because a count a few seconds old is still useful, and an error is not. Copying each record to several machines (replication) means one failure loses no data.
Durability. The system may hold writes in memory to absorb bursts, but memory does not survive a crash. Once a user is told that a like was recorded, it may reach durable storage late, but it must reach it.
Reading Progress
0%
On This Page
Functional Requirements
Non-Functional Requirements