How do you spend the first ten minutes of a system design round?

First, agree what the system does

The opening move is to convert a four-word prompt into a bounded feature list, out loud, and get it acknowledged. "Design a photo-sharing app" could mean upload and view, or it could mean upload, a ranked feed, comments, direct messages, stories and content moderation. Those are not the same system and they do not have the same bottleneck. Say which two or three features you are treating as the core, name the ones you are consciously excluding, and ask whether that matches what the interviewer wants graded.

This costs perhaps two minutes and it protects the other fifty. The commonest way to fail a design round is not to design something badly, it is to design the wrong thing competently and discover it at minute forty. Excluding a feature explicitly also reads as judgement rather than ignorance: "I will leave moderation out of the core design and come back to it, because it is an asynchronous pipeline hanging off upload rather than something that shapes the storage layer" tells the interviewer you know where it would attach.

Then ask only the questions whose answers move the architecture

A clarifying question earns its time if a different answer would make you draw a different diagram. Read-to-write ratio qualifies, because it decides whether your effort belongs in caching and fan-out or in ingestion and durability. Whether the feed must be strictly chronological qualifies, because chronological ordering across many sources is a different problem from a ranked feed that is allowed to be approximate. Whether data is global or regional qualifies, because it drives replication topology and it may drag in residency constraints. How stale a view may be qualifies, because "seconds" and "immediately" buy completely different designs.

Questions that do not qualify: the exact user count to three significant figures, the programming language, the cloud provider. If the interviewer will not give you a number, supply one yourself and label it. "I will assume forty million daily active users; tell me if you want a different order of magnitude" is a strong move, because the arithmetic that follows is now reproducible and the interviewer can redirect you with one word.

The estimate, derived from those assumptions

Take that photo app with the scope reduced to upload, a home feed, and photo viewing. Assume forty million daily active users, each opening the feed five times a day, and assume ten per cent of them post one photo per day.

Feed reads are 40M × 5 = 200 million per day. Divided by 86,400 seconds that is about 2,300 requests per second on average. Traffic is never flat, so assume a 3x diurnal peak and design for roughly 7,000 feed requests per second. Uploads are 40M × 0.1 = 4 million per day, about 46 per second average and perhaps 140 per second at peak. The ratio between them, roughly 50:1, is the single most load-bearing number in the estimate: it says the write path can be served by a modest, well-partitioned ingestion tier while the read path needs caching and edge delivery.

Storage splits into blobs and metadata, and they differ by orders of magnitude. At an average of 1.5 MB per original plus derived thumbnail and display sizes, call it 2.5 MB stored per upload: 4 million uploads a day is about 10 TB per day, or roughly 3.6 PB per year, which means object storage with lifecycle tiering rather than anything resembling a database. Metadata is a row of a few hundred bytes — owner, timestamp, dimensions, blob key, caption — so 4 million rows a day at 500 bytes is about 2 GB per day, which is unremarkable for years.

Egress is the number that decides your delivery architecture, and candidates routinely skip it. If a feed response renders twenty images at about 30 KB each for the display variant, one feed load pulls roughly 600 KB of image bytes. At 7,000 feed loads per second that is about 4 GB/s of image egress, against a JSON payload that is a rounding error beside it. No origin tier is a sensible place to serve that, so a CDN is not an optimisation here, it is load-bearing, and the design must make blob URLs cacheable and immutable to let it work.

One more derivation is worth doing because it sizes your service tier rather than your storage. By Little's Law, concurrency equals arrival rate multiplied by service time, so 7,000 requests per second at 80 ms per request means about 560 requests in flight at any moment. That tells you roughly how many connections, threads or goroutines the fleet must sustain, and it turns "add more servers" into a number you can defend.

What the numbers are for

Each figure should immediately cash out into a decision, and saying so is what separates estimation from arithmetic theatre. The 50:1 ratio justifies spending your remaining time on fan-out and caching. The 4 GB/s of egress mandates a CDN and immutable blob keys. The 3.6 PB per year rules out storing images anywhere but object storage and raises lifecycle tiering as an explicit cost lever. The 140 peak uploads per second, being small, tells you that synchronous durable write plus asynchronous thumbnail generation is comfortably affordable, which is genuinely useful because it means you do not need to defend a complicated ingestion pipeline you were about to over-engineer.

Where the ten minutes is usually wasted

The failure worth naming is estimating with confidence and then never referring to a single number again. Interviewers watch for this specifically, because reciting 86,400 and multiplying some invented averages is a rehearsed move that costs nothing and proves nothing. The estimate has value only as an argument: it exists so that when you later say "this needs a cache", the interviewer already agreed to the premise that makes it true. An estimate that never constrains a later choice is dead weight, and a candidate who produces one has shown they memorised the ritual rather than understood why it opens the round.

The mirror-image failure is refusing to commit. If you spend eight minutes interrogating the interviewer for requirements, you have handed them the design work and consumed the time you needed to do yours. State assumptions, mark them as assumptions, and start.

Every number you produce in the first ten minutes should be traceable to an assumption you said out loud, and should force a decision you make later — if it does neither, it was theatre.