11. Interview Blueprint

A repeatable 4-step framework for approaching any system design interview question. Practice this until it becomes automatic.

Step 1: Understand the Problem & Set Scope (5—7 min)

Before designing anything, clarify what you are building. Ask questions:

• What are the core features? (explicit and implicit)
• How many users? Monthly active users (MAU), concurrent users?
• What is the read/write ratio? (e.g., news feed: write-heavy for authors, read-heavy for consumers)
• What are the latency requirements? (real-time vs eventual)
• What devices/platforms should we support? (mobile, web, API)
• What are the non-functional requirements? (availability, durability, consistency)

Step 2: Estimate Scale (3—5 min)

Do back-of-the-envelope calculations to size the system:

# Example: Twitter-like news feed
MAU: 500 million
Daily active users (DAU): 200 million (40% of MAU)
Tweets per day: 500 million
Reads per day: 20 billion (each user reads ~100 tweets/day)

Storage per tweet: ~1 KB (text + metadata)
Daily storage: 500M × 1KB = 500 GB
Yearly storage: 500 GB × 365 ≈ 182 TB

Bandwidth (writes): 500M tweets × 1KB / 86400s ≈ 5.8 MB/s
Bandwidth (reads): 20B reads × 1KB / 86400s ≈ 230 MB/s

Know common numbers: 1M requests/day ≈ 12 req/s, 1 PB = 1000 TB, typical DB row size, SSD vs HDD latency, network round trips.

Step 3: High-Level Design (10—15 min)

Draw the system architecture with major components. Focus on breadth, not depth:

• Clients: Mobile app, web browser, API consumers
• Load balancer: DNS or reverse proxy
• API Gateway / Web servers: Handle requests, authentication, rate limiting
• Application services: Business logic (possibly microservices)
• Data stores: Primary DB, cache, object storage, queues
• CDN: For static assets and cached content

Explain why you chose each component. "I'm putting a cache here because the read-to-write ratio is 40:1 and we need sub-10ms response times."

Step 4: Deep Dive & Infrastructure Decisions (10—15 min)

Now go deeper into the most interesting or critical parts. The interviewer will guide you here. Common deep dives:

• Database schema: Tables, indexes, shard key design
• Data flow: End-to-end path of a request or data item
• API design: REST, GraphQL, or RPC endpoints
• Consistency vs availability: CAP trade-off decisions
• Failure scenarios: What happens when each component fails?
• Monitoring & alerting: Key metrics, dashboards

# Deep dive: DB schema for URL shortener
Table: urls
  id          BIGINT (auto-increment, primary key)
  short_key   VARCHAR(7) UNIQUE INDEX
  long_url    TEXT
  created_at  DATETIME
  user_id     INT (FK to users table)
  click_count BIGINT DEFAULT 0

Final Step: Summarize & Identify Trade-offs (2—3 min)

End with a concise summary and acknowledge the trade-offs you made:

• "We chose eventual consistency for read performance and accepted stale data for up to 1 second."
• "We prioritized write availability over strong consistency using leaderless replication."
• "If this system needs to scale 10x further, we would add another caching tier and introduce data archival for older records."

Common Pitfalls

• Jumping to solutions without clarifying requirements
• Over-engineering (adding Kafka and microservices when a simple DB suffices)
• Ignoring failure scenarios
• Not using the whiteboard/diagram effectively
• Going silent while thinking — verbalize your thought process