Section 2: Two Private Yeses - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract. The functional half says what must work in the demo: a deck that respects both people's preferences and never re-shows a face she has swiped on for at least 60 days, like and pass, an instant match, chat, and the safety controls. The non-functional half is numbers: swipe p99 < 200 ms, deck fetch p99 < 300 ms, 99.95% for swipes and chat but 99.9% for the deck, a block effective everywhere in under 1 s, and one invariant above the rest: exactly one match per mutually-liking pair, never zero, never two. A per-data-type consistency table closes it.
The interviewer taps the assumptions: "Good. Now what does 'working' mean? What would you demo, and what would you measure?"
"Matches should be correct" can't be tested. "Two people who like each other get exactly one match, and the second one to swipe sees it in the swipe response" can.
The Functional Contract
Every user is both a viewer and a candidate. Priya, the 29-year-old product designer in Austin from Section 1, is looking for men aged 27–35 within 15 miles, and she also sits in other people's decks.
Must ship
- Profile and photos (six on average). A photo is visible only after moderation.
- Preferences: genders, age range, maximum distance.
- Location update. The server keeps the position and never hands it back to anyone.
- The deck: nearby candidates who fit both sides' preferences, never re-showing a profile she has swiped on for at least 60 days (swipes are forgotten 60–90 days later; Section 7 explains why).
- Like and pass. Swipes are final. Free tier: 100 likes per 12 hours.
- Match on mutual like, with instant feedback for the second liker and a notification for the first.
- Matches list, and 1:1 chat between matched users only.
- Unmatch, block, report. A block makes two people invisible to each other everywhere, permanently.
- Push notifications for matches and messages.
Out of scope, with reasons
| Excluded | Why it can wait |
|---|---|
| Paid tiers, Super Like, Boost | Ranking and visibility tweaks on top of the like and the deck: they need seams, not day-one code |
| Passport | A deck query aimed at another location, not a new core path |
| Rewind | Final swipes keep the swipe API idempotent and simple |
| Video chat | Reuses chat authorization; the media relay is a separate system |
| Group chat | Matching is pairwise; 1:1 keeps chat authorization to one check |
All but group chat return in Section 11's Follow-up Feature Evolution.
Interviewer: "'Don't re-show a swiped profile' is a strong promise. Why a window, not forever?"
You: "Forever is unbounded storage and an unbounded 'already seen' structure per user. Swipe rows expire after 90 days, and the seen-set keeps them out for at least 60. After that a pass becomes a second chance and an unanswered like lapses. If product decides likes must never expire, we keep received likes indefinitely and split the seen-set into recent and archived parts. Section 5 puts storage numbers on it."
Interviewer: "Filtering on Priya's preferences alone is simpler."
You: "And wasteful. If Priya is outside Marco's age range, her like on him can never become a match. That card burns one of her swipes and one of her 100 likes on nothing."
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson