System Design: Tinder (Walnut Match: S2 Geoshards, Two-Way Ranking, Race-Free Matches, Real-Time Chat)
Goal: Design a dating app like Tinder. Ours is Walnut Match. People see nearby profiles as cards and swipe right to like or left to pass. Two likes make a match and open a chat.
We plan for 50 million monthly users, 2 billion swipes a day and 24 million matches a day. That is about 23,000 swipes a second on average, and 140,000 a second of design capacity, the capacity we keep always on.
At the evening peak, the busiest time of day, 5 million people are online.
Walnut Match is our design. Tinder is run by Match Group. Tinder's published facts are used as evidence, always with their year.
1. What We Are Building
🔒 Premium section
2. Requirements and Scale
2.1 What the System Must Do
| ID | Requirement |
|---|---|
| FR1 | Create a profile with photos and settings. The settings are gender, who you are interested in, an age range and a maximum distance of 2 to 160 km (section 3). |
| FR2 | Show a deck of nearby people where both sides fit each other's settings. Emma sees Jake only if she also fits his age range and distance (section 6). |
| FR3 | Swipe like, pass or Super Like. Paid users can Rewind their last swipe (section 8). |
| FR4 | When both people like each other, create exactly one match and tell both of them (section 8). |
| FR5 | Chat after a match, with sent, delivered and read marks (section 10). |
| FR6 | Paid users can see who already liked them, in a list called "Likes You" (section 9). |
| FR7 | Boost a profile for 30 minutes, and look at another city with Passport (sections 6 and 18.1). |
| FR8 | Report, block and unmatch. After a block, neither person sees the other again (section 12). |
| FR9 | Check that a real, present person is signing up (section 12). |
| FR10 | Export or delete all of a user's data on request (section 13). |
2.2 How Well It Must Do It
Speed targets use two words. p50 is the time that half of all requests beat. p99 is the time that 99 of every 100 requests beat, so it shows the slow tail that a few unlucky users feel.
A zone is one part of a cloud region with its own power and network. Losing one zone must not lose data.
| ID | Requirement | Target |
|---|---|---|
| NFR1 | Swipe call, inside our servers | p99 under 100 ms |
| NFR2 | Next page of the deck, from memory | p99 under 150 ms |
| NFR3 | "It's a match" | The second liker sees it in the swipe answer. The first liker gets it within 2 s if online, and within about 30 s in the worst case |
| NFR4 | Message delivery to an online user | p50 under 300 ms, p99 under 1 s |
| NFR5 | Uptime for swiping and chat | 99.95% a month |
| NFR6 | Lost data | No accepted swipe or message is lost, except the last few seconds if a whole region is lost (section 18.3). "OK" is sent only after the data is saved in at least 2 zones |
| NFR7 | Swiped profiles | Not shown again for at least 60 days, usually up to 90. At most 0.1% of unseen profiles wrongly hidden in the normal case |
| NFR8 | Blocks | Enforced in the API within 1 s. An old photo link works for at most 1 hour |
| NFR9 | Location | Raw GPS is never stored |
Where the targets come from:
- NFR1 and NFR2. Our choice. A swipe and the next card must feel instant on a phone, and the network adds its own delay on top.
- NFR3. Our choice. The 30 s worst case is a background repair job that finishes any match a crash left half done (section 8.5).
- NFR4. The p50 is Tinder's 2019 average delay (Tinder engineering blog, 2019). The p99 is our choice.
- NFR5. Our choice. A 30-day month has 43,200 minutes, and 0.05% of that is about 22 minutes of downtime.
- NFR6. Our choice. Two zones means one lost zone still holds every accepted swipe.
- NFR7. Three 30-day filter buckets keep a swipe for 60 to 90 days (section 7.3). The 0.1% comes from the Bloom filter sizes in section 7.
- NFR8. Our choice. A block must hold even if the app is bypassed, and photo links expire after 1 hour (section 11).
- NFR9. Distance features can reveal where a person lives (KU Leuven, 2024), so we keep only a rounded point (section 5.6).
2.3 The Numbers
These are planning numbers, all our assumptions unless marked. Section 14 turns them into servers.
Three load words appear in the whole post. The daily average is a day's total spread evenly over 86,400 seconds. The evening peak is 2 times the daily average, our assumption, because people swipe most in the evening.
Design capacity is 3 times the evening peak. The stores and the swipe path keep this much running at all times, because databases cannot add capacity fast enough during a sudden spike (section 14.2).
| What | Number | How we got it | Section |
|---|---|---|---|
| Monthly users (MAU) | 50 million | Close to Tinder's size. Tinder does not publish this number (Match Group, 2024) | 14 |
| Daily users (DAU) | 20 million | 40% of MAU. Core users open a dating app most days | 14 |
| Stored profiles | 150 million | MAU plus quiet accounts not yet closed. Tinder closes accounts after 2 years without use (Tinder privacy policy, 2026) | 3 |
| Swipes a day | 2 billion | 20 million DAU × 100 swipes. Tinder reported 2 billion daily actions of all kinds (Tinder engineers on the AWS blog, 2020), so ours is cautious | 8 |
| Swipes a second | 23,000 average, 46,000 evening peak, 140,000 design capacity | 2,000,000,000 ÷ 86,400 = 23,148. × 2 = 46,296. 46,000 × 3 = 138,000, rounded up | 8, 14 |
| Likes a day | 800 million | 40% of swipes are likes | 9 |
| Matches a day | 24 million | 3% of likes are the second like of a pair: 800 million × 3%. Tinder had 26 million (2017) | 8 |
| Messages a day | 300 million | 20 million DAU × 15 messages | 10 |
| Messages a second | 3,500 average, 6,900 evening peak, 21,000 design capacity | 300,000,000 ÷ 86,400 = 3,472. × 2 = 6,944. × 3 = 20,833 | 10 |
| Online at the evening peak | 5 million | 25% of DAU have the app open at once | 10 |
| Deck builds a day | 60 million | 20 million DAU × 3 builds, mostly when the app opens with an old deck | 6 |
| Deck builds a second | 700 average, 1,400 evening peak, 4,200 design capacity | 60,000,000 ÷ 86,400 = 694. × 2 = 1,389. × 3 = 4,167 | 6 |
| Photo requests a second | 46,000 average, 92,000 evening peak, 276,000 design capacity | 2 photo views per swipe, the first photo plus, on average, one more. 23,000 × 2 = 46,000 | 11 |
| Pair rows | About 43 TB | 180 billion rows (90 days of swipes) × 80 bytes = 14.4 TB per copy, × 3 copies | 8 |
| Messages stored | About 66 TB a year | 300 million × 200 bytes = 60 GB a day, about 21.9 TB a year per copy, × 3 copies | 10 |
| Photos | About 525 TB | 150 million profiles × 5 photos × 0.7 MB for all sizes of one photo | 11 |
These sums are shown only here. Section 14 uses the results to count servers and does not repeat the sums.
2.4 Out of Scope
We leave out payments and subscription billing, video calls, ads, group features such as Double Date, and AI photo tools.
Paid features appear only where they change the design. Rewind changes the swipe row (section 8), and Passport changes location (section 18.1). "Likes You" needs an inbox of likes (section 9), and Boost changes ranking (section 6).
3. The API and the Core Data
🔒 Premium section
4. High-Level Design
🔒 Premium section
5. Deep Dive: Location, S2 Cells and Geoshards
🔒 Premium section
6. Deep Dive: Building the Deck
🔒 Premium section
7. Deep Dive: The Seen Set
🔒 Premium section
8. Deep Dive: Swipes and Race-Free Matches
🔒 Premium section
9. Deep Dive: Hot Profiles and the Likes Inbox
🔒 Premium section
10. Deep Dive: Chat
🔒 Premium section
11. Deep Dive: Photos
🔒 Premium section
12. Deep Dive: Trust and Safety
🔒 Premium section
13. Deep Dive: Privacy Law and Sensitive Data
🔒 Premium section
14. Peaks and Capacity
🔒 Premium section
15. What Happens When Each Part Goes Down
🔒 Premium section
16. Bottlenecks
🔒 Premium section
17. Trade-Offs We Chose and Rejected
🔒 Premium section
18. Multi-Region
🔒 Premium section
19. In the Interview (45 and 60 Minutes)
🔒 Premium section
20. Further Reading
🔒 Premium section
Explore the Technologies
🔒 Premium section