Section 3: Seventy Thousand Swipes, Seven Hundred Matches - Scale Estimation & Workload Analysis

Executive Summary: This section derives every load figure the design leans on, step by step, from one assumption about daily users. Three findings shape everything after it. Swipes are the write firehose, about 70K a second at peak, which become about 90K rows written. Photos are the bandwidth, about 110 Gbps at peak, which belongs to a CDN. Recommendations are the compute, about 1.4M candidate scorings a second. The match, the moment users actually care about, runs at about 700 a second: small enough to get exactly right.

The interviewer caps the marker. "Tens of millions of daily users. Where does the load go?"

You start with one person. Priya opens the app at 8:40 p.m. on Sunday and swipes about 100 times before bed: roughly 30 likes, 70 passes. "She's one daily user's share," you say. "Multiply her by twenty million and the system tells us what it's made of."

Step 1: Users and the Peak Factor

Registered accounts     100M
Monthly active (MAU)     50M   ≈ discoverable profiles (active in 30 days, not hidden or banned)
Daily active (DAU)       20M
Peak factor              3× average

Interviewer: "Why 3×? You're global. Time zones should flatten it."
You: "Partly. But dating is local, and each region peaks in its own evening, worst on Sunday nights. Time zones smooth the global curve, not the load on one region's cluster. So I size for 3×, and I'll keep a separate number, Dating Sunday at twice the normal peak, for Section 9."