System Design Interview: A Repeatable Framework (With Examples)

System design interviews reward clarity, tradeoffs, and structured thinking. A strong candidate doesn't jump into Kafka; they first lock down the problem.

1) Confirm the goal (and what “success” means)

Ask 3–5 questions to avoid building the wrong thing:

• How many users? Peak RPS? Global or one region?
• Latency target (p50/p95)? Availability target?
• Data retention? Compliance requirements?
• Read-heavy or write-heavy? Any real-time needs?

2) Define the MVP scope

State what you will and won't build.

• “MVP: create posts, read feed, like. Not doing DMs or recommendations yet.”

3) Core entities and data model

Write down the main objects and their relationships:

• User, Post, Follow, Like, Comment
• Cardinality: 1-to-many, many-to-many

4) API surface (keep it boring)

Show a small set of endpoints:

POST /posts
GET  /feed?cursor=...
POST /posts/{id}/like
GET  /users/{id}

5) High-level architecture

Start with a simple architecture, then scale it:

• CDN + app servers
• Primary DB (Postgres / MySQL)
• Cache (Redis) for hot reads
• Background workers for fanout / indexing

6) The hard part: scalability decisions

Common pivots:

• Pagination: cursor-based over offset-based for large feeds
• Read path: cache hot feeds, avoid N+1 queries
• Write path: async work (queues) for non-critical tasks

7) Tradeoffs (say them explicitly)

Interviewers love this:

• “Precompute feed improves latency but increases write cost.”
• “Strong consistency vs availability: what matters here?”

8) A compact checklist (use this every time)

• Requirements (functional + non-functional)
• Data model
• APIs
• Architecture diagram
• Bottlenecks + mitigations
• Tradeoffs
• Observability (logs/metrics/traces)

If you can walk through this calmly in 30–40 minutes, you're already ahead of most candidates.