Requirements and Back-of-the-Envelope Estimation

Every design starts with what the system must do (functional requirements) and how well it must do it (non-functional: latency, availability, scale, cost), followed by rough numbers for traffic, storage and bandwidth.

Interviewers and customers rarely give you a full specification. "Build a photo site" hides a hundred decisions. The first ten minutes of any design are about asking and estimating, not drawing boxes.

flowchart LR
  ASK["Ask: who, what, how much"] --> FR["Functional requirements"]
  ASK --> NFR["Non-functional requirements"]
  NFR --> NUM["Estimate: QPS, storage, bandwidth"]
  FR --> API["API and data model"]
  NUM --> ARCH["Architecture choices"]
  API --> ARCH
  %% step ASK: Clarify users, main use cases, scale and constraints before designing anything.
  %% step FR: Functional requirements are features: upload a photo, view a feed, share a link.
  %% step NFR: Non-functional requirements are qualities: p99 latency, availability, durability, cost, compliance.
  %% step NUM: Rough numbers tell you whether one server is enough or you need sharding and a CDN.
  %% step API: Features become API endpoints and a data model.
  %% step ARCH: Numbers and APIs together drive the architecture, not the other way round.

Functional vs non-functional

Type	Examples	Question to ask
Functional	Users upload photos, follow others, see a feed	"What must a user be able to do?"
Non-functional	p99 < 200 ms, 99.9% available, photos never lost, EU data stays in EU	"How fast, how reliable, how big, how cheap?"

Write down what is out of scope too ("no comments in v1"). It keeps the design small.

SLA, SLO, SLI

SLI – what you measure: share of requests under 200 ms, share of successful requests.
SLO – your internal target: 99.9% of requests succeed each month.
SLA – a contract with customers, usually looser than the SLO, with penalties.

Estimation toolkit

Fact	Value
Seconds per day	~86,400 ≈ 10⁵
1 million requests/day	≈ 12 requests/second on average
Peak factor	2–10 × average (sales, evenings)
1 KB × 1 billion	1 TB

Worked example – photo site: 10 M daily users, each views 50 photos and uploads 0.1 per day.

Reads: 10 M × 50 ÷ 86,400 ≈ 5,800 QPS average, ~20,000 at peak.
Writes: 10 M × 0.1 ÷ 86,400 ≈ 12 uploads/s.
Storage: 1 M photos/day × 2 MB ≈ 2 TB/day, ~730 TB/year before replicas.
Read/write ratio ~500:1 → caching and a CDN matter far more than write speed.

Measure the current system

When you redesign an existing service, measure it first: latency of one request, throughput under load, and resource use. Numbers from a load test beat guesses.

Traps: drawing Kafka and Kubernetes before knowing the traffic; forgetting peak vs average; estimating storage without replicas, backups and growth; treating the SLA as the engineering target instead of a stricter SLO.