Estimation & requirements Study Portal

TL;DR

The first five minutes of a system design interview decide the next forty. You turn a vague prompt ("design a URL shortener") into a short list of functional requirements (what it does), non-functional requirements (how well: latency, availability, durability, consistency), and numbers (users, requests per second, bytes stored, bytes moved). The numbers are not there to be precise; they exist to tell you which design is forced. 100 writes per second fits on one Postgres; 100,000 does not. A read-to-write ratio of 100:1 says cache; a 5 TB-per-day ingest says object storage and partitioning. Estimate to one significant figure, say your assumptions aloud, and convert every number into a constraint you then design against.