The 6-Step Design Framework

The 6-Step Design Framework

System design interviews are deliberately open-ended: "Design a chat app" in 45 minutes, with no single right answer. What's actually being assessed is how you think:

• Do you clarify before building?
• Do you reason with numbers?
• Can you produce a working design, then find and fix its weak points?
• Can you explain trade-offs?

A consistent framework keeps you from freezing, rambling, or spending 30 minutes on one database table. These six steps work for any question. The case-study walkthroughs in this course (Design Twitter / X, Design a URL Shortener, Design Netflix and others) all follow them.

Timing is flexible. Some interviewers want to reach deep dives quickly, and some skip the API step. Read the room, and ask if unsure: "Would you like me to go deeper here, or move on?"

Step 1: Clarify requirements

Never start drawing immediately. Ask questions that change the design:

• Functional: which features are in scope? Pick 2–4 core ones and say explicitly what you're leaving out. For example: "I'll focus on posting and the home timeline; search and DMs are out of scope unless you'd like them."
• Users and scale: how many users, how active, and is growth expected?
• Read/write ratio: read-heavy (feeds, URL redirects) or write-heavy (logging, telemetry)?
• Latency and availability targets.
• Consistency needs: what must be strongly consistent (payments, inventory, bookings), and what can be eventual (feeds, counters, recommendations)?
• Special constraints: geography, compliance, mobile clients, cost sensitivity.

Write the agreed requirements where the interviewer can see them. You'll refer back to them when justifying decisions.

Step 2: Back-of-the-envelope estimation

Estimates exist to drive decisions, not to show off arithmetic. Round aggressively:

500M new posts/day ÷ ~100,000 s/day ≈ 5,000 writes/s (peak maybe 3×)
Reads 100× writes                   ≈ 500,000 reads/s  → caching is mandatory
Post ≈ 1 KB × 500M/day              ≈ 500 GB/day ≈ 180 TB/year → needs sharding

Then state the implication out loud: "Half a million reads per second means the read path must be served from cache, not the database." An estimate with no conclusion is wasted time. Useful numbers are in Back-of-the-Envelope Estimation.

Step 3: Define the API

A few endpoints make the scope concrete, and expose design decisions early:

POST /v1/posts                    { text, mediaIds[] }         → { postId, createdAt }
GET  /v1/timeline?cursor=&limit=20                             → { posts[], nextCursor }
POST /v1/users/{id}/follow

It's worth pointing out details such as cursor-based pagination (stable under inserts), idempotency keys for payments and other non-repeatable writes, and whether real-time updates need WebSockets or server-sent events.

Step 4: Data model and storage

List the core entities and, more importantly, how they're accessed:

• Post(postId, authorId, text, createdAt): read by ID, and by author ordered by time.
• Follow(followerId, followeeId): queried in both directions.

Choose storage to fit those patterns, and justify it: "Relational for users and payments because we need transactions. A wide-column store for posts and timelines because it's a huge, write-heavy workload queried by key." See SQL vs NoSQL Trade-offs.

Step 5: High-level design

Draw the simplest design that meets the functional requirements end to end: clients, load balancer, services, databases, caches, queues, object storage and CDN. Then walk one or two requests through it: "A post goes to the post service, is stored, and an event goes to the queue; fan-out workers update timelines."

At this stage the design should be correct, not yet optimized. A complete simple design beats a half-finished sophisticated one.

Step 6: Deep dives and trade-offs

Now improve the design where it would break. Pick the 2–3 hardest problems for this particular system, or ask the interviewer which interests them:

• Hot paths at scale: caching strategy, fan-out, precomputation.
• Data growth: sharding key choice, hot partitions, rebalancing.
• Consistency: read-your-writes, duplicate processing, idempotency, transactions across services.
• Failure handling: what happens when the cache, a queue consumer or a whole region fails? Timeouts, retries with backoff, circuit breakers, graceful degradation.
• Operations: monitoring, alerting, deployments.

For each one, present options, the trade-off, and your choice: "Fan-out on write makes reads fast but is expensive for accounts with millions of followers, so I'll use a hybrid." This is the part that separates strong candidates.

Finish with a summary

In the last minute or two: recap the design against the requirements, name the main trade-offs you made, and list what you'd do next with more time (analytics, multi-region, security, cost optimization).

Habits that make a strong impression

• Think aloud. Silent thinking gives the interviewer nothing to evaluate.
• Justify with requirements and numbers, not with fashion ("because Netflix uses it").
• Name trade-offs unprompted. Every choice has a cost. Saying what it is shows depth.
• Welcome hints. When the interviewer asks "what if this fails?", they're pointing you to where they want to go.
• Don't over-engineer. Microservices, Kafka and Kubernetes for a system with 1,000 users is a red flag, not a plus.

Follow-up questions this topic invites — and their answers

Q: What if the interviewer interrupts and changes direction? A: Follow them. They're steering toward what they want to assess. Briefly note where you were ("I'll come back to storage if there's time"), and address their question.

Q: How detailed should the capacity estimation be? A: Only enough to make decisions: order of magnitude for QPS, storage and bandwidth, plus the conclusion each one leads to (caching, sharding, CDN). Rounded numbers are expected, and precise arithmetic wastes time.

Q: How do you choose which deep dives to do? A: Choose the components that the requirements and estimates show will break first: the hot read path, the largest dataset, the strongest consistency requirement, or the operation with the biggest fan-out. Ask the interviewer if several are equally plausible.

Q: Is it bad to say "I don't know"? A: No, if you follow it with reasoning: "I haven't used X, but it would need to do Y, so I'd evaluate it on these criteria." Bluffing specifics is much riskier than honest reasoning.

Q: How is a senior-level answer different? A: More proactive trade-off discussion, attention to failure modes and operations, pragmatic choices sized to the actual requirements, and the ability to go deep on at least one area (storage internals, consistency, or large-scale data flow) while keeping the whole design coherent.