Section 2: The Contract Nobody Writes Down - Requirements (Functional & Non-Functional)

Executive Summary: This section converts Section 1's clarified assumptions into a contract: five functional requirements phrased as demos you could run in front of the interviewer, and non-functional requirements with numbers attached — latency, availability, durability, and the scale envelope. The centerpiece is the requirement almost every candidate omits: an explicit accuracy tolerance for the displayed count. The interviewer's hanging question — "must the count be exact?" — gets its answer here, and it is neither "yes" nor "no" but a negotiated tolerance, captured in one line the rest of the module will keep quoting: counts are exact at rest, approximate in motion.

Section 1 ended with one thread dangling: you asked whether the count must be exact, and the interviewer returned it — "What do you think?" A test of whether you treat exactness as a default you inherit or a requirement you negotiate. Requirements time is when you answer, in writing, before a single box is drawn.

Functional Requirements: Sentences You Can Demo

A functional requirement earns its place only if you could demonstrate it in two minutes with a phone and a test account. Vague verbs ("handle likes robustly") score nothing; demo-able sentences become tests the final design must pass.

• F1 — Like a post. An authenticated user taps the heart; the system records that this user likes this post. Demo: tap, reload, the heart is filled.
• F2 — Unlike a post. The same tap on a filled heart removes the like. Demo: tap again, reload, the heart is empty. This requirement is why a bare counter can never be the whole design: removing a like requires knowing the like exists.
• F3 — A repeated action is a no-op. Liking an already-liked post changes nothing; so does unliking an already-unliked one. Demo: double-tap, or replay the same request — the count moves by exactly one, then by exactly zero. This is idempotency written as a functional requirement, not an operational nicety. Priya's double-tap on @astra's post, and her subway-tunnel retry, are F3's test cases: a design that double-counts her fails a stated requirement, not merely a best practice.
• F4 — Every post shows its like count. Wherever a post renders — feed, profile, permalink — the count renders with it.
• F5 — Every post shows whether I liked it. The viewer's own state is part of the display: a filled or empty heart, correct for this viewer, on every device. F4 and F5 carry — as Section 8 will show — radically different consistency price tags, and separating them now is what makes that section possible.
• F6 — Deferred, by name. A paginated "who liked this" list and multi-emoji reactions are out of scope today, explicitly plausible tomorrow (Section 11).

Key Insight: F3 separates candidates. Most treat "don't double-count" as an implementation detail to remember later; writing it as a functional requirement means every design review must answer "where is the no-op enforced?" — and the answer (Section 5) turns out to be a single storage-engine constraint, not a pile of application logic.

Quick check before moving on: