Courses › System Design › Getting Started

Delivery Framework

The 45-minute structure: requirements, entities, API, high-level design, deep dives.

The biggest predictor of a good system design interview isn't knowledge — it's structure. A clear structure keeps you from wandering, makes sure you finish a working design, and leaves time for the deep dives where you show seniority.

Here's the framework we recommend for a 45-minute interview:

Requirements -> Core Entities -> API -> [High-Level Design] -> {Deep Dives}

1. Requirements (~5 minutes)

Functional requirements

These are the "users should be able to…" statements. Aim for the top three. Every system has dozens of possible features; the interview is about the core ones.

For a Twitter-like system:

  • Users should be able to post tweets
  • Users should be able to follow other users
  • Users should be able to see a feed of tweets from users they follow

Explicitly put other features out of scope ("I'll skip DMs and search unless you'd like me to cover them"). It shows you can prioritize.

Non-functional requirements

These are the "the system should be…" statements — the qualities that make the design interesting. Phrase them in context, with numbers where possible:

  • The system should be highly available; eventual consistency for the feed is acceptable (a tweet can take a few seconds to appear)
  • Feed loads should return in < 200ms
  • The system should support 100M daily active users

Useful checklist: consistency vs availability (see CAP Theorem), latency targets, scale and read/write ratio, durability, security/privacy, and anything unique to the problem (e.g. "a seat must never be sold twice").

[!TIP] Back-of-the-envelope estimates: only when they change a decision Don't spend five minutes computing storage you never use. Estimate when the answer will drive a design choice — "is this read-heavy enough to need a cache?" or "does this fit on one machine?" See Numbers to Know.

2. Core entities (~2 minutes)

List the nouns your system stores and exchanges. For Twitter: User, Tweet, Follow. Don't design full schemas yet — you'll add fields as you go, once you understand how the data is accessed.

3. API (~5 minutes)

Define the contract between clients and your system. Usually a REST API maps cleanly from your functional requirements:

POST /v1/tweets
body: { "text": "..." }
→ 201 { "tweetId": "..." }

POST /v1/users/{userId}/follows
→ 204

GET /v1/feed?cursor={cursor}&limit=20
→ 200 { "tweets": [...], "nextCursor": "..." }

[!WARNING] Never put the user ID in the request body for "who am I" The current user comes from the authentication token, not from a field the client controls. Interviewers notice this.

See API Design for when to choose GraphQL, gRPC, WebSockets or SSE instead.

4. (Optional) Data flow (~3 minutes)

For data-processing systems — a web crawler, an analytics pipeline — it helps to list the stages data moves through before drawing anything:

  • Fetch seed URLs from the frontier
  • Download HTML
  • Extract text and links
  • Store text, enqueue new links

5. High-level design (~10–15 minutes)

Now draw boxes and arrows. Go through your API endpoints one at a time and build up the design needed to satisfy each:

Client -> API Gateway -> [Tweet Service] -> (Tweets DB)
Client -> API Gateway -> [Follow Service] -> (Follows DB)
Client -> API Gateway -> [Feed Service] -> (Tweets DB)

Rules of thumb:

  • Keep it simple first. A straightforward design that works beats a sophisticated one that's half-finished. You'll fix bottlenecks in the deep dives.
  • Narrate the data flow. "When a user posts, the request hits the tweet service, which writes to the tweets table and returns the ID…"
  • Write down key columns next to your databases as they become relevant.
  • Flag issues without solving them yet. "Fetching the feed by querying every followed user is going to be slow — I'll come back to that."

6. Deep dives (~10–15 minutes)

This is where you earn your level. Use the deep dives to:

  • Satisfy your non-functional requirements. "We said feed loads in < 200ms — the current design doesn't achieve that for users following 2,000 accounts. Let's precompute feeds."
  • Address edge cases and bottlenecks. The celebrity with 50M followers. The hot seat everyone is trying to book.
  • Respond to the interviewer. If they probe something, that's the deep dive they care about.

[!INTERVIEW] Lead at senior+, but leave room Senior and staff candidates should propose the deep dives themselves: "The two things I'm most worried about are fan-out for celebrities and feed latency — I'd like to start with fan-out." But don't monologue. Pause, and let the interviewer redirect you.

Common pitfalls with this framework

  • Treating it as a script. It's a default, not a checklist. If the interviewer wants to jump to a deep dive, go.
  • Endless requirements. Five minutes, top three features, a handful of non-functional requirements. Move on.
  • Optimizing during the high-level design. Get something working end to end first.