Week 10 · Day 3 · 2026-09-30 WED · FULL · attempt + original reading
Tinder full: profile preferences, geo feed, swipe, mutual match
今日目标
Build a 25-35 minute Tinder design where the feed is a cache/index projection and match creation is a unique pair transition.
| 08:50-09:00 | Set target One sentence: low-latency nearby feed without reshowing swiped profiles. |
|---|---|
| 09:00-10:05 | Attempt + Hello Interview reading Read Tinder through HLD and four functional paths. |
| 10:05-10:45 | Decision note Separate profile truth, geo/preference index, swipe write path, and Match pair uniqueness. |
| 10:45-10:55 | Spoken close Explain why swipes scale separately from profiles. |
| 14:30-16:15 | NeetCode Tag · Intervals Exactly three contiguous slots; each slot is 30m solve + 5m evidence. |
| 20:30-21:15 | Recall / Mock 20:30-21:15 Tinder English recall outline and Chinese explainer review. |
Live canonical source anchors
Daily anchors retain the original Hello Interview heading text.
| Project | Exact canonical source heading | Disposition | Use |
|---|---|---|---|
| Tinder | Understand the Problem | required reading | dating/feed/swipe/match domain |
| Tinder | Functional Requirements | required reading | profile preferences, stack, swipes, match notification |
| Tinder | Non-Functional Requirements | required reading | consistent swipe match, 20M DAU, <300ms feed, no reshow |
| Tinder | The Set Up | required reading | scope feed and swiping over chat/photos |
| Tinder | Planning the Approach | required reading | one functional path at a time |
| Tinder | Defining the Core Entities | required reading | User, Swipe, Match |
| Tinder | The API | required reading | profile, feed, swipe APIs |
| Tinder | High-Level Design | required reading | Profile Service, Swipe Service, Swipe DB, push notification |
| Tinder | 1) Users can create a profile with preferences (e.g. age range, interests) and specify a maximum distance. | required reading | preference write path |
| Tinder | 2) Users can view a stack of potential matches | required reading | geo/filter feed path |
| Tinder | 3) Users can swipe right / left on profiles one-by-one, to express "yes" or "no" on other users | required reading | write-heavy swipe path |
| Tinder | 4) Users get a match notification if they mutually swipe on each other | required reading | mutual match notification path |
DDIA decision links
| Week 10 decision | Exact DDIA subsection | Design consequence |
|---|---|---|
| How should Tinder represent geo/feed secondary filters? | Ch7 - 分片与二级索引 | The profile source of truth is separate from geo/preference secondary indexes and feed caches. |
Algorithm block
| Slot | Problem | Pattern | Invariant | Bug risk | Time | Space |
|---|---|---|---|---|---|---|
| 7 | Interval List Intersections NEW · 30m solve + 5m evidence | two-pointer sweep | Move the pointer with smaller end after recording overlap. | Forgetting zero-length inclusive intersections. | O(n+m) | O(1) extra |
| 8 | Meeting Rooms NEW · 30m solve + 5m evidence | overlap detection | After sorting starts, any start < previous end conflicts. | Equal endpoint should not conflict. | O(n log n) | O(1) extra |
| 9 | Meeting Rooms II NEW · 30m solve + 5m evidence | min-heap resources | Heap contains end times of active meetings only. | Pop only once instead of while eligible. | O(n log n) | O(n) |
Output and repair
| Deliverable | Tinder 30m attempt: profile/feed/swipe/match schema, APIs, feed cache, swipe partition key. |
|---|---|
| Repair rule | If the design paginates a SQL query as the feed, replace it with indexed candidates plus cache and no-reshow filter. |
| Artifacts | Tinder Chinese explainer Tinder Chinese audio Tinder English recall |
| English recall | English recall: defend freshness, reservation, race recovery, fairness, and observability without reading notes. |
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.