A 5-Step Framework for Any System Design Problem

Key terms in plain words

• Functional requirement: something the system must do, such as "shorten a URL".
• Non-functional requirement: how well the system must do it, such as how fast, how reliable or how big.
• QPS: queries per second, the number of requests the system gets each second.
• Latency and p99: latency is how long one request takes. "p99 under 50 ms" means 99 out of 100 requests finish in less than 50 ms.
• Availability: the share of time the system works. "99.99%" allows only about 52 minutes of downtime a year.
• Back-of-the-envelope estimation: quick rough maths, like you would do on the back of an envelope, to learn how big the problem is.
• API (Application Programming Interface): the list of requests that other programs can send to your system, and the answers they get.
• Access pattern: how your data is read and written, for example "look up one row by its code".
• Bottleneck: the one part that is slowest, so it limits the whole system.
• SPOF (single point of failure): one part that, if it breaks, stops the whole system.
• Load balancer: a server that spreads incoming requests across several servers.
• Cache: a fast, small store that keeps copies of data that is read often, so you do not ask the slow database every time.
• CDN (content delivery network): a network of servers around the world that keeps copies of files close to users.
• Queue: a line of tasks waiting to be done. A program adds a task to the end, and a worker takes tasks from the front.
• Stateless: a server is stateless when it keeps no user data between requests, so any server can answer any request.
• Kafka: a popular system that stores a stream of messages so that many programs can read them. Microservices are many small programs that each do one job and talk over the network.
• Metadata: data about other data, for example the owner and expiry date of a paste.

The five steps at a glance

A rough time budget for a 45–60 minute interview:

In a real design document, the same steps become the sections of the document.

Step 1: Clarify requirements

Never start designing right away. Ask questions until the problem is clear (post 6).

Functional requirements: what does it do?

• Who are the users? (consumers, businesses, internal teams)
• What are the core use cases? Pick the 3–5 most important ones.
• What is out of scope (not part of this design)? Say it out loud: "I will skip payments and admin tools for now."

Non-functional requirements: how well must it do it?

• Scale: daily active users (people who use it each day), requests per second, data size, and growth.
• Latency: how fast must the key actions feel (p99 targets, post 8)?
• Availability: how bad is downtime (post 9)? Which parts are critical?
• Consistency: is slightly old (stale) data OK, or must every user see the exact latest data (posts 27–28)?
• Durability: may we ever lose saved data? (Durable data stays safe even after crashes.)
• Read/write ratio: is it read-heavy (feeds, product catalogues) or write-heavy (logs, chat)?
• Limits from geography, security, compliance (legal rules) and cost.

Write them down, and check them with the other person:

Step 2: Back-of-the-envelope estimation

Do quick maths to learn the size of the problem (post 10):

• Traffic: the average QPS and the peak QPS (the busiest moment), for reads and writes separately.
• Storage: per item × items per day × retention.
• Bandwidth: QPS × response size.
• Memory: how much hot data (data that is read often) to keep in a cache. The 80/20 rule says that about 20% of the data gets about 80% of the reads.

Always end with "so this means…":

• "Only ~40 writes per second, so one primary database handles writes easily."
• "~12,000 reads per second at peak, so we need caching and replicas."
• "About 6 TB over 10 years, which fits in a sharded or single large database."

Do not spend 15 minutes on arithmetic. Round the numbers a lot. The goal is the order of magnitude, which means "is it about 10, 1,000 or 1,000,000?".

Step 3: Define the API and data model

API. Write down the main endpoints (the URLs a client can call) or operations (posts 30–34). In the example, a 301 redirect is cached by browsers, and a 302 redirect is not:

POST /v1/urls     { longUrl, customAlias?, expiresAt? }  → 201 { shortUrl }GET  /{code}      → 301/302 redirect to longUrl

Think about:

• idempotency for creates (it means that sending the same request twice has the same effect as sending it once, post 34),
• pagination for lists (returning a long list in small pages),
• authentication (checking who the caller is) and rate limits (a cap on how many requests one caller may send, posts 43 and 49),
• sync vs async: does the client need the result now (synchronous), or can the work run later as a background job (asynchronous, post 18)?
• whether REST, gRPC, GraphQL or WebSockets fits best. These are different styles for programs to talk to each other (posts 30–33).

Data model. List the core entities (the main kinds of things you store, like a user or a URL), their key fields, and the access patterns. In the example, PK means primary key, the field that identifies each row:

url_mappings: code (PK), long_url, created_at, expires_at, owner_idAccess pattern: lookup by code (very hot), insert (rare)

Then choose the storage based on those patterns (posts 20 and 29): relational, key-value, wide-column, document, search or object storage.

Step 4: High-level design

Draw the main components and the flow of data that cover the core use cases from start to finish. Start simple, then improve it step by step:

Walk through each core use case on the diagram: "When a user creates a URL, the request goes here, then here… When someone visits a short URL, it goes here…"

Tips:

• Use the standard building blocks (post 11). Do not invent strange new components.
• Mark what is synchronous and what is asynchronous.
• Show where the data lives and which service owns it (the only one allowed to change it).
• Keep it readable: 6–12 boxes, not 40.

Step 5: Deep dives and scaling

Now go deeper on the hardest or most important parts. Pick 2–3 topics that matter most for this system, or follow what the interviewer asks:

Scaling:

• Where is the bottleneck when traffic grows 10 or 100 times?
• Cache hot data (posts 15–16). CDN for static content (post 14).
• Read replicas (extra copies of the database that only answer reads, post 24). Sharding (splitting data across several databases), with a clear shard key, the field that decides which database holds a row (posts 25–26).
• Queues to soak up sudden spikes of work (posts 18 and 35).

Reliability:

• SPOFs and redundancy (spare copies) across AZs, which are separate data centres (post 40).
• Timeouts, retries and circuit breakers (a circuit breaker stops calling a service that keeps failing, posts 41–42).
• Rate limiting and load shedding (load shedding means dropping some requests on purpose so the rest still work, posts 43–44).
• Backups and DR (disaster recovery: how you get running again after a big failure, post 45).

Data correctness:

• Consistency needs per feature (post 28).
• Transactions (a group of changes that all happen or none happen), idempotency, handling duplicates and keeping the right order (posts 21, 34 and 37).

Operability and security:

• Monitoring and SLOs: what would you alert on? An SLO (service level objective) is a reliability target, such as "99.9% of requests succeed" (posts 46–48).
• AuthN / AuthZ, sensitive data and abuse. AuthN (authentication) checks who you are. AuthZ (authorization) checks what you are allowed to do (posts 49–52).
• Deployments: how do you ship changes safely (post 58)?

Good deep dives compare options: "We could do A or B. A is simpler but fails when X. Given our requirement of Y, I would choose B."

Wrap-up: trade-offs and next steps

Finish by summing up:

• Key decisions and why (for example "hybrid fan-out, because of celebrity accounts". Fan-out means copying one post to many followers' feeds).
• Trade-offs accepted ("feeds may be a few seconds stale").
• Risks and bottlenecks you would watch.
• What you would do next with more time ("multi-region, better ranking, analytics").

A mini example: "Design Pastebin" in 5 steps

1. Requirements: users paste text and get a link, and anyone with the link can read it. Pastes can optionally expire and are up to 1 MB. The system is read-heavy (about 10:1), and pastes must not be lost.
2. Estimation: 1M new pastes a day ≈ 12 writes/s. 10M reads a day ≈ 120 reads/s (peak around 500/s). With an average paste of 10 KB, that is 10 GB a day ≈ 3.6 TB a year.
3. API and data: POST /pastes returns {id}, and GET /pastes/{id} returns the content. Metadata (data about the paste, like owner and expiry) goes in a database. The content goes in object storage, a cheap service for storing big files (post 17).
4. High-level design:

5. Deep dives: making IDs (random Base62 vs counters; Base62 uses the 62 characters a–z, A–Z and 0–9), caching popular pastes, cleaning up expired pastes, abuse (spam, malware, rate limits), and CDN caching rules.

Wrap-up: this is a simple, read-heavy design. Caching and a CDN (a network that serves copies of files from places near the user) give most of the scale, and object storage keeps the database small.

Common mistakes

• ❌ Jumping into details (Kafka partitions, database choice) before the requirements are clear.
• ❌ Designing for Google scale when the real need is 1,000 users.
• ❌ Silent thinking. Explain your reasoning as you go. The process matters.
• ❌ Buzzword architecture: adding trendy tools like microservices, Kafka, Kubernetes and GraphQL without saying why.
• ❌ Ignoring failure: acting as if every component always works.
• ❌ No trade-offs: showing one option as perfect. Every choice has a cost.
• ❌ Spending all the time on one part and never finishing the design from start to finish.
• ❌ Not checking back with the interviewer or stakeholders (people who care about the result), for example "Does this match what you had in mind?".

Communication tips

• Think out loud, and say your assumptions clearly ("I will assume 50M daily users").
• Check in at the end of each step.
• Start simple, then improve: "Version 1 is a single database. At 10 times the traffic we would add…"
• Use numbers to support your decisions.
• Admit uncertainty: "I am not sure about the exact limits of X, but I would check with a load test."