System Design Interview Framework

System design interviews are open-ended. Without a framework, it's easy to dive too deep too fast or miss key areas. Use this 45-minute structure consistently.

The RADAD Framework

Phase	Time	What you're doing
R — Requirements	5 min	Clarify functional + non-functional requirements
A — API Design	5 min	Define the interface (REST endpoints or events)
D — Data Model	5 min	Schema, DB choice
A — Architecture	10 min	High-level component diagram
D — Deep Dive	20 min	Scale bottlenecks, edge cases, tradeoffs

Step 1: Requirements (5 min)

Functional Requirements — what does the system do?

"Design Twitter/X"

Clarify:
- Can users post tweets? Reply? Retweet?
- Home timeline feed? How many tweets?
- Direct messages? Search? Trending topics?
- Which features are in scope for this interview?
→ "I'll focus on posting tweets and home timeline"

Non-Functional Requirements — how well must it perform?

- Scale: 300M DAU, 500M tweets/day
- Latency: timeline load < 200ms p99
- Availability: 99.99% (< 1 hour/year downtime)
- Consistency: eventual OK for timeline, strong for counters?
- Read:Write ratio? (usually high read for social)

Step 2: Capacity Estimation (optional, 3 min)

Tweets/day: 500M
Tweets/second: 500M / 86400 ≈ 6000 writes/sec
Reads/second: 6000 × 100 (read-heavy) = 600,000 reads/sec

Storage:
  Tweet: 140 chars ≈ 280 bytes
  500M/day × 280 bytes = 140GB/day → 50TB/year

Step 3: API Design (5 min)

POST /api/v1/tweets
  Body: { text, mediaIds[] }
  Returns: { tweetId, createdAt }

GET /api/v1/timelines/home
  Params: userId, cursor, limit=20
  Returns: { tweets: [...], nextCursor }

GET /api/v1/users/{userId}/tweets
  Params: cursor, limit

Step 4: High-Level Architecture (10 min)

Draw a box diagram:

Client → CDN → Load Balancer → [Tweet Service | Timeline Service | User Service]
                                        ↓               ↓
                                   [DB/Cache]      [Redis Timeline Cache]
                                        ↓
                                  [Message Queue] → [Fan-out Worker]

Step 5: Deep Dive (20 min)

Pick 2-3 hard problems to discuss deeply:

Fan-out on write vs fan-out on read for timeline
Database sharding strategy
Cache invalidation for hot users
Rate limiting design
Failure scenarios: what if the fan-out queue backs up?

Common Interview Traps

Diving too deep too fast: Draw the big picture first, then go deep.
Forgetting non-functional requirements: always ask about scale, latency, availability.
One-size-fits-all answers: justify your database and architecture choices.
Not discussing tradeoffs: "This approach is better because... the tradeoff is..."

Interview Tips

Think out loud — interviewers evaluate your thought process, not just the final design.
Justify every decision: "I'll use Redis here because the timeline is read-heavy and we need sub-millisecond latency."
Ask before assuming: "Should I focus on read performance or write throughput?" shows systems thinking.

System Design Interview Framework

System design interviews are open-ended. Without a framework, it's easy to dive too deep too fast or miss key areas. Use this 45-minute structure consistently.

The RADAD Framework

Phase	Time	What you're doing
R — Requirements	5 min	Clarify functional + non-functional requirements
A — API Design	5 min	Define the interface (REST endpoints or events)
D — Data Model	5 min	Schema, DB choice
A — Architecture	10 min	High-level component diagram
D — Deep Dive	20 min	Scale bottlenecks, edge cases, tradeoffs

Step 1: Requirements (5 min)

Functional Requirements — what does the system do?

"Design Twitter/X"

Clarify:
- Can users post tweets? Reply? Retweet?
- Home timeline feed? How many tweets?
- Direct messages? Search? Trending topics?
- Which features are in scope for this interview?
→ "I'll focus on posting tweets and home timeline"

Non-Functional Requirements — how well must it perform?

- Scale: 300M DAU, 500M tweets/day
- Latency: timeline load < 200ms p99
- Availability: 99.99% (< 1 hour/year downtime)
- Consistency: eventual OK for timeline, strong for counters?
- Read:Write ratio? (usually high read for social)

Step 2: Capacity Estimation (optional, 3 min)

Tweets/day: 500M
Tweets/second: 500M / 86400 ≈ 6000 writes/sec
Reads/second: 6000 × 100 (read-heavy) = 600,000 reads/sec

Storage:
  Tweet: 140 chars ≈ 280 bytes
  500M/day × 280 bytes = 140GB/day → 50TB/year

Step 3: API Design (5 min)

POST /api/v1/tweets
  Body: { text, mediaIds[] }
  Returns: { tweetId, createdAt }

GET /api/v1/timelines/home
  Params: userId, cursor, limit=20
  Returns: { tweets: [...], nextCursor }

GET /api/v1/users/{userId}/tweets
  Params: cursor, limit

Step 4: High-Level Architecture (10 min)

Draw a box diagram:

Client → CDN → Load Balancer → [Tweet Service | Timeline Service | User Service]
                                        ↓               ↓
                                   [DB/Cache]      [Redis Timeline Cache]
                                        ↓
                                  [Message Queue] → [Fan-out Worker]

Step 5: Deep Dive (20 min)

Pick 2-3 hard problems to discuss deeply:

Fan-out on write vs fan-out on read for timeline
Database sharding strategy
Cache invalidation for hot users
Rate limiting design
Failure scenarios: what if the fan-out queue backs up?

Common Interview Traps

Diving too deep too fast: Draw the big picture first, then go deep.
Forgetting non-functional requirements: always ask about scale, latency, availability.
One-size-fits-all answers: justify your database and architecture choices.
Not discussing tradeoffs: "This approach is better because... the tradeoff is..."

Interview Tips

Think out loud — interviewers evaluate your thought process, not just the final design.
Justify every decision: "I'll use Redis here because the timeline is read-heavy and we need sub-millisecond latency."
Ask before assuming: "Should I focus on read performance or write throughput?" shows systems thinking.