How to Pass the System Design Interview Round in 45 Minutes

Passing a system design round takes 7 steps: clarify requirements, estimate scale, define the API, design the data model, sketch the high-level architecture, deep dive on the hardest parts, and discuss tradeoffs. Interviewers grade how you reason through ambiguity, not recall of famous architectures. With 3 to 4 weeks of practice, including at least 6 timed designs, you can run this sequence inside a 45-minute round with time left for questions. This guide is for mid-level and senior engineers facing a design round at FAANG or a similar company. It is not an introduction to distributed systems; you should already know what caches, queues and databases do.

What you need before you start

• Working knowledge of load balancers, caches, SQL and NoSQL databases, message queues and replication.
• A whiteboard tool you are fast in (Excalidraw, a drawing pad, or the tool your recruiter names).
• A list of 6 to 10 classic prompts: URL shortener, news feed, chat, rate limiter, notification system, file storage.
• 3 to 4 weeks with two or three 45-minute timed sessions per week, ideally with a reviewer.

Step 1: Clarify the functional and non-functional requirements

Spend the first few minutes agreeing what the system must do (core features only) and how well it must do it: scale, latency, availability, consistency. Write both lists where the interviewer can see them.

Why it matters: Alex Xu's widely used framework for a 45-minute round budgets 3 to 10 minutes to understanding the problem and establishing scope, and warns that answering without understanding the requirements is a red flag. Make latency goals precise: Google's SRE book notes a high percentile such as the 99th or 99.9th shows a plausible worst case, while the median shows the typical case.

Example (URL shortener):

Functional:
  - POST a long URL, get a short code
  - GET a short code, redirect to the long URL
  - Out of scope: accounts, custom aliases, analytics
Non-functional:
  - Redirect p99 under 100 ms
  - Highly available reads; a short delay before a new link works is OK
  - Links never collide and never expire

Common mistake: Designing features nobody asked for, such as analytics dashboards, before the core flow works.

Step 2: Estimate the scale with quick arithmetic

Turn the requirements into rough numbers: requests per second for reads and writes, storage over several years, and bandwidth. State every assumption, round aggressively, and keep it to two or three minutes.

Why it matters: Estimates decide whether you need sharding, caching or a queue at all. Keep the classic latency reference in mind: a main memory reference is about 100 ns, a round trip within a datacenter about 500,000 ns, and a disk seek about 10,000,000 ns, so a cache hit in memory is orders of magnitude cheaper than a disk read.

Example (illustrative assumptions, not real traffic data):

Assume 100M new links per month, 100 reads per write.
Writes: 100M / (30 x 86,400 s) = ~40 per second
Reads:  ~40 x 100 = ~4,000 per second (plan for 3-5x peaks)
Storage: 100M x 12 x 5 years = 6B links x ~500 bytes = ~3 TB
Codes:  base62 with 7 characters = 62^7 = ~3.5 trillion codes

Common mistake: Spending ten minutes on exact math. The interviewer wants orders of magnitude.

Step 3: Define the API

Write the two to four endpoints the client needs, with methods, parameters and responses. This fixes the boundary of the system before you draw boxes behind it.

Why it matters: A precise API exposes hidden requirements such as retries. Stripe's API, for example, lets clients send an idempotency key of up to 255 characters so a retried POST does not create a second object, and Stripe may prune keys after 24 hours.

Example:

POST /v1/links
  headers: Idempotency-Key: <uuid>
  body:    { "long_url": "https://example.com/very/long/path" }
  201:     { "code": "aZ3kQ9x", "short_url": "https://sho.rt/aZ3kQ9x" }

GET /{code}
  301/302: Location: <long_url>
  404:     unknown code

The architecture the next steps build toward:

Common mistake: Skipping the API and drawing boxes immediately, which leaves the interviewer guessing what the system actually exposes.

Step 4: Design the data model

List the entities, their key fields, the primary access pattern for each, and the storage engine that fits that pattern. Name the partition key explicitly.

Why it matters: The storage choice drives cost and latency for years. Discord moved its trillions of messages from Cassandra to ScyllaDB in 2022 and went from 177 nodes to 72.

Example:

Table links  (key-value store, partition key = code)
  code        string(7)   primary key
  long_url    string(2048)
  created_at  timestamp
Access pattern: get by code (99% of traffic), put once
Why key-value: single-key lookups, no joins, easy horizontal sharding

Common mistake: Choosing a database first and justifying it later. Start from the query.

Step 5: Sketch the high-level design

Draw the request path end to end for each core API call: client, load balancer, stateless services, cache, storage, and any async workers. Walk the interviewer through one read and one write and get their buy-in before going deeper.

Why it matters: Xu's framework gives this 10 to 15 minutes and calls it getting buy-in. For read-heavy systems, a cache in front of storage is the standard move: Meta's TAO paper describes a social graph cache serving a billion reads and millions of writes each second.

Example wording: "On a GET, the API server checks the cache by code. On a hit, it returns a redirect. On a miss, it reads the key-value store, fills the cache, then redirects. On a POST, the server gets a unique ID, base62-encodes it, writes the row, and returns the code. Does this cover what you had in mind before I go deeper?"

Common mistake: Drawing 15 boxes with no arrows.

Step 6: Deep dive on the hardest components

Pick the two parts with the most risk, or ask the interviewer which they prefer, and go into detail: algorithms, failure modes, hot keys, replication, and how you would measure it.

Why it matters: This is where senior signal comes from, and Xu's framework allots it the largest block, 10 to 25 minutes. Measured results are the language to use: Discord reports p99 latency for fetching historical messages dropped from 40-125 ms to 15 ms after its storage redesign.

Example (ID generation deep dive): "Hashing the long URL and truncating risks collisions, so I would rather hand each API server a block of 10,000 IDs from a central counter. Servers allocate locally with no coordination, and if one crashes we lose at most one unused block, which is fine with 3.5 trillion possible codes. For a viral link, the cache absorbs the hot key, and I would replicate that key across cache nodes if one node saturates."

Common mistake: Deep diving into the easy part (the load balancer) while the hard part (unique IDs) stays hand-waved.

Step 7: Discuss tradeoffs and wrap up

Close by naming the main tradeoffs you made, what breaks first as traffic grows 10x, and what you would change with more time.

Why it matters: Every design gives something up. Eric Brewer, who formulated CAP, wrote that the "two of three" view is misleading because partitions are rare, so the real choice is what to do during a partition. Xu's framework also warns that "over-engineering is a real disease of many engineers".

Example wording: "I chose availability over strict consistency for reads: during a partition, a brand new link might 404 for a few seconds, which we agreed was acceptable. At 10x traffic, the first bottleneck is cache memory for hot codes, then the ID allocator. With more time I would add rate limiting on POST to stop abuse."

Common mistake: Presenting the design as perfect.

How to know it worked

• After 3 to 4 weeks, you finish all 7 steps on an unseen prompt in 45 minutes in at least 4 of your last 6 practice sessions.
• Your estimates land within an order of magnitude when a reviewer checks them.
• Every box in your diagram has an arrow, a purpose and a failure answer.
• You volunteer at least two tradeoffs before the interviewer asks.

Troubleshooting

• If you run out of time before the deep dive: cap requirements and estimates at 10 minutes combined and practice with a visible timer.
• If the interviewer keeps redirecting you: stop and ask which part they want to explore, then go there.
• If you blank on a component: describe the problem it must solve (for example, "I need unique IDs without coordination") and reason from that.

FAQ

How long is a system design interview?

Most system design rounds run about 45 to 60 minutes. Alex Xu's common framework for a 45-minute session allocates 3 to 10 minutes to scope, 10 to 15 to the high-level design, 10 to 25 to the deep dive, and 3 to 5 to wrapping up.

Do junior engineers get system design rounds?

It depends on the company and level. New graduate loops at many large companies focus on coding, while mid-level and senior loops usually include at least one design round. Ask your recruiter which rounds are in your loop.

Should I memorize real architectures like Twitter or Uber?

Study them for patterns, but do not recite them. Interviewers give constraints that differ from the real system, and a memorized answer usually ignores those constraints. Know why each pattern exists, such as caches for read-heavy loads or queues for spiky writes, and apply it to the stated numbers.

How detailed should back-of-envelope estimates be?

Get the order of magnitude right and move on. Round to powers of ten, state your assumptions out loud, and use the result to justify decisions such as sharding or caching. Two or three minutes is usually enough for this step.

To recap: clarify requirements, estimate scale, define the API, model the data, sketch the architecture, deep dive on the hard parts, and close with tradeoffs. The quickest way to find your weak step is a timed session with someone who has run real design rounds, so book an anonymous system design mock interview and review the recording afterwards. For company-specific loops, see the FAANG prep guide and the FAANG company interview guides.