How to Approach System Design

System design interviews and real-world architecture sessions share the same structure: clarify requirements, estimate scale, then design incrementally. Skipping requirements is the most common mistake — building a system that handles 10 million users when the product has 100 is engineering waste. Skipping scale estimation means discovering too late that your choices cannot handle the load. Start every design with two questions: what does the system need to do (functional requirements), and what constraints must it meet (non-functional: latency, throughput, availability, consistency). Then do back-of-envelope math. A system handling 1 million requests per day averages ~12 requests per second — easily handled by one server. At 100 million per day you are at 1,200 RPS and need horizontal scaling. Numbers drive decisions.

// Common mistake: designing before clarifying
"Let's use microservices, Kafka, and Redis."
// → Over-engineered for 1,000 users
// → May be wrong for 10M users
// → Team spends weeks on the wrong problem

// Step 1: Functional requirements
"Users can post, follow others, see a feed."

// Step 2: Scale estimation
DAU: 1M users
Posts per day: 5M  →  ~58 writes/sec
Feed reads: 50M   →  ~580 reads/sec

// Step 3: Design for those numbers
// Single Postgres + read replica handles this.
// No Kafka needed yet.