Requirements and estimation

When it comes up

• At the start of every design question, before any boxes are drawn.
• Whenever the prompt is short and open, such as "design a link shortener".
• When the interviewer gives you a number: use it, and work out what it implies.
• Later, whenever a choice depends on scale: "is one database enough?" is an estimate question.

The core idea

Split requirements into three lists. Functional: the three to five things a user can do, written as verbs (create a link, follow a link, see click counts). Non-functional: scale, latency, availability, consistency and durability targets. Out of scope: what you will deliberately not design today. Read the lists back and get agreement; it takes a minute and saves the next forty.

Then estimate with round numbers. A day has about 100,000 seconds (86,400), so requests per day divided by 100,000 is requests per second; multiply by two or three for the peak. Work out the read to write ratio, the size of one record, and storage over the retention period. Every estimate should end in a conclusion that changes the design; a number with no consequence is wasted time.

A worked estimate

Assume 100 million new links a month and 100 reads for every write.

Writes:  100M / 30 days / ~86,400 s   ≈ 40 per second, ~100 at peak
Reads:   100 x writes                 ≈ 4,000 per second, ~10,000 at peak
Storage: 500 bytes x 100M a month x 12 months x 5 years ≈ 3 TB

So: reads dominate, which puts a cache in front of the redirect path;
3 TB fits on a few database nodes, so sharding can wait;
40 writes a second needs no write queue.

Trade-offs to name

• Consistency against availability for the core path: must every read see the latest write?
• Latency targets against cost: a 50 ms target and a 500 ms target lead to different designs.
• Precision against speed: round numbers and orders of magnitude are enough; say when one would change your mind.
• Building for today's scale against next year's: say which you are designing for.

Common mistakes

• Drawing boxes before agreeing what the system must do.
• Listing a dozen requirements and designing for none of them properly.
• Estimating without drawing a conclusion from the numbers.
• False precision: 38.58 requests a second instead of about 40.
• Designing for the average when the peak is three times higher.

How to explain it out loud

Open with a sentence that buys you the time: "Before I design anything, I'd like to agree on the main use cases and the scale." Then ask two or three focused questions and state your assumptions where the interviewer leaves you to choose. In Devana's system design rubric, requirements scoping is the largest single communication metric, so these minutes are worth the most.

Use the numbers out loud when you make later choices: "At around 10,000 reads a second at peak, I want a cache in front of the database." Referring back to your own estimate is what driving the discussion sounds like, and it keeps the design anchored to the question.