Cut the scope, then put a number on every requirement
A design without requirements solves the wrong problem, and a design without numbers can't justify anything.
- Name the 3 core actions as verbs. For Twitter: post, follow, read the timeline. Everything else hangs off these.
- Cut features out loud: "I'll leave out DMs, search and ads." Cutting is a sign of seniority, not laziness.
- Give every non-functional requirement a number: latency, availability, consistency, durability and scale.
- No number from the interviewer? Propose one: "I'll assume 100M daily users; tell me if that's off."
- Talk about p99, not averages: the slowest 1% of requests are the ones users complain about.
What each target forces
- Latency (p99 under 200 ms): caches, a CDN, precomputation.
- Availability (99.99%): redundancy across zones, no single points of failure, graceful degradation.
- Durability (never lose an order): replication, a write-ahead log, backups.
- Scale (100M DAU): sharding, queues, horizontal scale.
- Consistency (strong for payments, eventual for likes): different stores per feature.
Numbers to know
- 99.9% allows about 8.8 hours of downtime a year; 99.99% about 53 minutes.
Why it protects you
- Once scope is written down, "and it should support video" at minute 30 becomes "that changes the storage estimate".