|
| 1 | +# Requirements (5 mins): |
| 2 | + |
| 3 | +## Functional Requirements |
| 4 | + |
| 5 | +> Identify core features (e.g., "Users should be able to post tweets"). Prioritize 2-3 key features. |
| 6 | +
|
| 7 | +1. users can start/stop/pause their activity (runs/rides) |
| 8 | +2. users should be able to check the activity data (route, distance, time etc) when running /riding |
| 9 | +3. users should be able to check history records, including friends |
| 10 | + |
| 11 | +## Non-Functional Requirements |
| 12 | + |
| 13 | +> Focus on system qualities like scalability, latency, and availability, consistency, security, durability, fault tolerance. Quantify where possible (e.g., "render feeds in under 200ms"). |
| 14 | +
|
| 15 | +1. the system should be highly available |
| 16 | +2. the app should work offline when no Internet |
| 17 | +3. the stats should be accurate |
| 18 | +4. should support 10m concurrent users |
| 19 | + |
| 20 | +## Capacity Estimation |
| 21 | + |
| 22 | +> Skip unnecessary calculations unless they directly impact the design (e.g., sharding in a TopK system). |
| 23 | +
|
| 24 | +route GPS data estimation: 100m DAU, 10m concurrent users, collect interval 5 secs, 30 min activity per day will generate 30 x 60 / 5 = 360 records, so around 36,000m records per day, each record we have around 40 Byte. |
| 25 | + |
| 26 | +Storage: 36,000m x 40 = 1440GB per day. 1500G x 360 = 180000x3G = 540000 GB = 540 TB |
| 27 | + |
| 28 | +QPS 3600m / 100k = 36k |
| 29 | + |
| 30 | +## Core Entities (2 mins) |
| 31 | + |
| 32 | +> Identify key entities (e.g., User, Tweet, Follow) to define the system's foundation. |
| 33 | +
|
| 34 | +- user |
| 35 | +- activity |
| 36 | +- route |
| 37 | +- friend |
| 38 | + |
| 39 | +# API/System Interface (5 mins) |
| 40 | + |
| 41 | +> Define the contract between the system and users. Prefer RESTful APIs unless GraphQL is necessary. |
| 42 | +
|
| 43 | +- POST /activity -> Activity, create an activity, body {type} |
| 44 | +- PATCH /activity/id, change status, body { status}, start, stop, pause, complete |
| 45 | +- POST /activity/id/route, update route geo tracking { geolocation} |
| 46 | +- GET /activities/page?mode=user|friend&page= |
| 47 | + |
| 48 | +# [Optional] Data Flow (5 mins) |
| 49 | + |
| 50 | +> Describe high-level processes for data-heavy systems (e.g., web crawlers). |
| 51 | +
|
| 52 | +# High-Level Design (10-15 mins) |
| 53 | + |
| 54 | +> Draw the system architecture, focusing on core components (e.g., servers, databases). Keep it simple and iterate based on API endpoints. |
| 55 | +
|
| 56 | + |
| 57 | + |
| 58 | + |
| 59 | +# Deep Dives (10 mins) |
| 60 | + |
| 61 | +> Address non-functional requirements, edge cases, and bottlenecks. Proactively improve the design (e.g., scaling, caching, database sharding). |
| 62 | +
|
| 63 | +## No internet connection |
| 64 | + |
| 65 | +We can save data in local db and sync to server later |
| 66 | + |
| 67 | +## Support 100 DAU, 10m concurrent users |
| 68 | + |
| 69 | +storage: 540TB/year |
| 70 | + |
| 71 | +- purge old storage of route date |
| 72 | +- shard data by time |
| 73 | +- use cold storage to save cost |
| 74 | +- compress the date |
| 75 | + |
| 76 | +QPS: 40k |
| 77 | + |
| 78 | +- use nosql database, time series database more specific |
| 79 | +- clients aggregate the data and use longer intervals if not in realtime view |
| 80 | +- shard the data by user id, activity id to distribute the load across servers |
| 81 | + |
0 commit comments