You are asked to design a photo-sharing service. What do you do in the first five minutes?

Clarify before designing. Ask what the core features are (upload, view a feed, follow people), who the users are and how many, what matters most (low latency for viewing, durability of photos, global reach), and what is out of scope. Write down the agreed functional and non-functional requirements and the scale, so every later choice can be justified against them. The trade-off is a few minutes spent not drawing, which pays back because you avoid designing the wrong system.

A service has 10 million daily active users and each makes 20 requests a day. Estimate the average and peak requests per second.

That is 200 million requests a day. A day has 86,400 seconds, which rounds to about 100,000, so the average is about 2,000 requests a second. Assuming the busiest moment is about three times the average, the peak is about 6,000 requests a second. State these as assumptions. The trade-off is precision against speed: a rough number is enough to decide between one server and many, and to see whether caching or sharding is needed.

Why draw the whole high-level design before going deep on any one component?

A complete simple design shows you can cover the whole problem and gives you and the interviewer a shared picture to refer to. Only then can you choose where to go deep, usually the part that is hardest or the bottleneck found in your estimates. Diving deep too early risks running out of time with half of the system missing, and optimising a part that was never the problem. The trade-off is that the first sketch is deliberately basic and you must be ready to improve it.

You have drawn your design. How do you show that it survives failure?

Go through each component and ask what happens if it fails: run several copies behind a load balancer, replicate data and fail over a database, put queues between slow or unreliable parts, and add timeouts, retries with backoff and idempotent operations so a retry is safe. Then say how you would notice, with metrics, alerts and health checks. The trade-off is cost and complexity: every extra copy and replica must be paid for and kept consistent.

The interviewer suggests a technology you have never used. What do you do?

Say honestly that you have not used it, then reason from the problem it solves. For example, "I have not used that, but if it is a distributed log, I would expect ordered, durable messages that several consumers can read independently, so here it would decouple the upload service from the processing". Link it to concepts you know and ask a clarifying question if needed. Interviewers value honest, structured reasoning over bluffing. The trade-off is that you may not give implementation details, but you show how you learn.

How to Approach a System Design Interview

Why you need a framework, and when to use it

A system design question such as "design a photo-sharing app" is deliberately open-ended. There is no single right answer, and in 45 minutes you cannot design everything. Without a plan, most people either jump straight to a favourite technology, or freeze. A framework is a fixed order of steps that keeps you moving, shows your thinking, and makes sure the important things get said.

It gives you two things interviewers always look for:

Clear communication: the interviewer can follow your reasoning, and can steer you when they want to.
Sound trade-offs: each choice is justified by the requirements and the numbers, and you name what you give up.

Use the framework when:

You face an open-ended design question, in an interview or in a real design review.
You are asked to "design X" and are unsure where to start.
You need to explain a design to someone else, such as a teammate or a manager.

Skip it, or adapt it, when:

The question is a narrow technical one, such as "how does a hash map handle collisions?": just answer it.
The interviewer steers you to a specific part: follow them, and return to the plan afterwards.
You are asked for a real production design with real data: the same steps apply, but the numbers come from measurements, not guesses.

Try it

Pick a system, then step through a back-of-the-envelope estimate (a quick, rough calculation done by hand). Each line builds on the one before it, and ends with what the numbers say about the design. Then inject a failure: a viral moment that multiplies traffic by 10.

A back-of-the-envelope estimate

Step 1 of 9 · Press Space to play, arrow keys to step

10 million daily users, each views 50 photos and uploads 0.5 photos a day.

Failure:

Daily active users10 millionthe assumption to state first

10 million daily users, each views 50 photos and uploads 0.5 photos a day. Estimates are rough on purpose: state each assumption, round to easy numbers, and move on.

All numbers are rough on purpose. Storage uses decimal units (1 TB = 1,000 GB). The per-server capacities are assumptions you would state aloud and test later.

Speed

Things to try:

Photo sharing: 10 million daily users give about 17,000 reads a second at peak and 10 TB of new photos a day, which is 18 PB in five years. One database cannot hold that, so the data must be spread out, and photos should come from a CDN.
URL shortener: the same 10 million users make only about 3,500 reads a second at peak and need under 1 TB in five years. One database and a small cache are enough. Scale decides the design, not the product name.
Chat app: writes are high (about 28,000 a second at peak), so the numbers say sharding from the start, which is a very different design from the other two.
Now switch on the viral spike for photo sharing: app servers jump from 18 to 176, and the database needs 35 read copies instead of 4 and 2 shards instead of 1. Storage does not change, because a spike makes systems busy but does not store more data. Your design needs a way to scale out fast or shed load.

The steps of a design interview

A common plan for a 45-minute interview. The times are a guide, and the interviewer may steer.

Step	What you do	Rough time	What the interviewer looks for	Common slip
1. Requirements	Ask what the system does (functional) and how well (scale, latency, availability, consistency). Agree what is out of scope	About 5 minutes	You ask before you assume	Starting to draw straight away
2. Estimates	Work out requests per second, storage and bandwidth from rough assumptions	About 5 minutes	You use numbers to make decisions	Fake precision, or skipping it
3. API and data	Sketch the main operations and the data they touch	5 to 10 minutes	A clean interface and a sensible data model	A model that cannot support the main query
4. High-level design	Draw a few boxes and follow one request through them	About 10 minutes	A simple, working design that covers the requirements	Too many boxes, too early
5. Deep dive	Go deep on the one or two hardest parts, often the bottleneck from your estimates	10 to 15 minutes	Depth, and trade-offs named out loud	Spreading thin, or going deep on the easy part
6. Wrap up	Revisit bottlenecks, failure, monitoring and what you would do with more time	A few minutes	You can critique your own design	Stopping when the diagram is done

Breadth first vs depth first

This is the main fork in the road: do you finish the whole picture before going deep, or go deep on the first interesting part?

Breadth first (recommended): draw a complete but simple design that meets the requirements, then choose where to go deep. It proves you can cover the whole problem, gives you and the interviewer a shared picture to point at, and lets you pick the deep dive from the numbers.
Depth first: start with the part you know best, such as the database, and perfect it. It can feel impressive, but the risk is running out of time with half the system missing, or polishing a part that was never the bottleneck.

A good habit: start simple, then make it scale. First a client, a server and a database that work. Then ask what breaks at the estimated scale, and fix that, one trade-off at a time.

How back-of-the-envelope estimation works

The aim is a number that is right to the nearest power of ten, quickly, to decide the shape of the design. Precision is not the point.

State the assumptions: daily active users, actions per user per day, the size of one item, how long data is kept. They are guesses, and saying them aloud is what matters.
Turn users into requests per day: users × actions per user.
Divide by the seconds in a day to get requests per second. A day has 86,400 seconds, and 100,000 is close enough for mental arithmetic.
Multiply for the peak: systems are sized for the busiest moment. A peak of two to three times the average is a common first guess.
Storage is writes per day × size of one item × days kept. Bandwidth is requests per second × size of one response.
Read the result: it tells you what to add. Many more reads than writes points to caching and read replicas. A huge storage or write rate points to sharding. Large files point to a CDN.

Use units that are easy to calculate: round to one significant figure, and use powers of ten (a thousand, a million, a billion). Write the units next to every number.

A framework vs winging it

Concern	A framework	Jumping straight to boxes	Reciting a memorised design
Covers the whole problem in the time	Yes	Often runs out of time	Only if the question matches
Shows how you reason	Yes	Hard to follow	No
Handles a new twist from the interviewer	Yes	Gets lost	Gets stuck
Justifies choices with numbers	Yes	No	No
Feels natural at first	Needs practice	Yes	Yes
Best for	Open-ended questions	Nothing in particular	A question you have seen before

A framework wins whenever the question is open-ended, which is nearly always. The cost is practice: do the steps on a few questions until they feel automatic.

Avoiding a single point of failure in your own design

An interviewer will always ask, in some form, "what happens if this dies?". Build the answer in as you go, rather than waiting to be asked:

Go through every box on your diagram and ask the question. A single server becomes several behind a load balancer. A single database gets replicas and a failover plan. A single queue or cache gets redundancy or a way to run without it.
For requests in flight, say how you survive a failure: timeouts, retries with backoff, and operations that are safe to repeat (idempotent).
For data, say where copies live and how you would restore it.
Say how you would notice: metrics, alerts and health checks.

The trade-off you accept: every extra copy costs money and adds work to keep copies in step. Say that out loud too, and match the level of redundancy to the requirement you agreed in step 1.

Common mistakes

Jumping straight to technologies. "I would use Kafka and Cassandra" before you know the requirements. Choose tools last, and say why.
Skipping requirements or estimates. You then cannot justify anything. Spend the first ten minutes on them.
Thinking in silence. The interviewer cannot give credit for thoughts they cannot hear. Narrate your reasoning.
Designing for the wrong scale. A design for a billion users when the question implied thousands is as wrong as the reverse. Let the numbers decide.
Ignoring failure. A design with no answer to "what if it dies?" looks unfinished.
Name-dropping tools without trade-offs. For each tool, say what problem it solves, and what it costs.
Never checking in. Pause to ask whether the interviewer wants to go deeper somewhere. They often have a direction in mind.

How to run the interview itself

Think out loud, and structure your answer with the steps above, so the interviewer always knows where you are.
Ask clarifying questions, and write down the requirements and the numbers so you can refer back to them.
Start simple, then scale: a working basic design first, then the bottleneck your estimates revealed.
Name trade-offs unprompted: consistency against availability, latency against cost, simplicity against scale.
Handle hints well: when the interviewer nudges you, take it as a gift, and say how it changes the design.
Be honest about what you do not know: reason from the problem the technology solves, and ask a question if needed.

Where you meet this framework in real systems

The interview is a short version of what engineers do at work: agree what to build, estimate its scale, sketch a design, and argue the trade-offs. Three examples are drawn out below, the first with a small script you can run, then more.

Example 1: Sizing a photo-sharing app on a napkin

Before a team builds anything, someone does the sums to see how big the system must be. A photo-sharing app with 10 million daily users, each viewing 50 photos and uploading half a photo a day, needs about 17,000 reads a second at peak and adds 10 TB of photos a day. Those numbers say the design needs a cache, a CDN and a database that is spread across machines. Open the example below to see the picture and the script in three languages.

Code: a back-of-the-envelope estimateSetup 1 short scriptCode runs in a second

The estimate turns user behaviour into requests, requests into a peak rate, and the peak rate and data size into the number of servers and the amount of storage. Each arrow multiplies by an assumption.

import math

SECONDS_PER_DAY = 86_400   # about 100,000: a handy number to round to in your head


def estimate(dau, reads_per_user, writes_per_user, write_kb, years, peak_factor, app_qps):
    """A back-of-the-envelope capacity estimate. Every input is a rough guess you state out loud.

    dau              daily active users
    reads_per_user   reads each user makes per day
    writes_per_user  writes each user makes per day
    write_kb         size of one stored write, in kilobytes (1 TB = 1,000,000,000 KB)
    years            how long data is kept
    peak_factor      busiest moment as a multiple of the daily average (3 is a common first guess)
    app_qps          requests per second one app server can handle (an assumption to check by testing)
    """
    reads_per_day = dau * reads_per_user
    writes_per_day = dau * writes_per_user
    peak_read_qps = reads_per_day / SECONDS_PER_DAY * peak_factor
    peak_write_qps = writes_per_day / SECONDS_PER_DAY * peak_factor
    storage_per_day_tb = writes_per_day * write_kb / 1e9
    return {
        "peak reads/s": round(peak_read_qps),
        "peak writes/s": round(peak_write_qps),
        "storage per day (TB)": round(storage_per_day_tb, 2),
        "storage for the retention period (PB)": round(storage_per_day_tb * 365 * years / 1000, 2),
        "app servers": math.ceil((peak_read_qps + peak_write_qps) / app_qps),
    }


# A photo-sharing app: 10 million daily users, each views 50 photos and uploads 0.5 photos a day.
print(estimate(10_000_000, 50, 0.5, 2000, 5, 3, 1000))

Run on the example inputs, all three versions print the same numbers: 17,361 peak reads a second, 174 peak writes a second, 10 TB of storage per day, 18.25 PB over five years, and 18 app servers. The JavaScript version runs on Node.js. The inputs and the 1,000 requests a second per server are assumptions, not measurements, which is exactly how you would present them in an interview.

Example 2: The six steps of a design answer

Every strong answer follows the same path, whatever the question. The picture below shows the order. The deep dive is the step where the answer is won or lost, because it is where the hard trade-offs are.

Start by clarifying requirements and estimating scale. Sketch the interface and data, draw a simple high-level design, then spend the most time going deep on the hardest part, and finish by critiquing your own design.

Example 3: A typical first draft

The first high-level design for a read-heavy service is usually the same shape: clients, a load balancer, several stateless app servers, a cache for hot data and a database. Starting here, you then use your estimates to decide what to add, such as read replicas, a queue for slow work or a CDN for large files.

Requests pass through a load balancer to several app servers. The servers check the cache first and only go to the database on a miss. Every box on this picture is a candidate for the question: what happens if it fails?

More real-world scenarios

4. Design documents at work

Before building a large feature, engineers write a design document that states the requirements, the scale, the proposed design and the alternatives that were rejected. It is the same structure as an interview answer, written down.

5. Architecture reviews

A team presents a design to other engineers, who ask about scale, failure and trade-offs. The questions are the ones an interviewer asks, which is why interviews use this format.

6. Capacity planning

Operations teams estimate next year's traffic and storage from user growth, so they can order machines or cloud capacity before the system runs out. It is the estimate from this lesson with real measurements in place of guesses.

7. Incident reviews

After an outage, a team asks what was assumed, what scale was expected and what broke first. A missing estimate or an unconsidered failure is often part of the answer.

8. Build or buy decisions

Choosing between running your own database and using a managed service depends on scale, cost and the effort of operating it. The numbers from an estimate make the argument concrete.

9. Startups planning for growth

A new product does not need a design for a billion users. Founders estimate the next stage of growth, build for that, and note what would break first, so that they know when to redesign.

Tools and managed services

Kind	Name	Notes
Reference	Latency numbers every programmer should know	A widely shared table of typical times for memory, disk and network operations, popularised by Jeff Dean. Useful for estimates.
Book	Designing Data-Intensive Applications	By Martin Kleppmann. A deep guide to the ideas behind modern data systems.
Book	System Design Interview	By Alex Xu. A collection of worked design questions in this framework.
Diagramming	Excalidraw	An open-source whiteboard tool for quick hand-drawn style diagrams.
Diagramming	diagrams.net (draw.io)	A free diagram editor that runs in the browser or as an app.
Spreadsheet	Any spreadsheet	A quick way to keep assumptions and calculations in one place, and to change one number and see the result.

The takeaway

Whenever you are asked to design something open-ended, the first box you draw is not a server, it is the list of requirements and the scale. Estimate, draw a simple design, find the bottleneck with your numbers, and say the trade-off each time you fix it.