Back to path
BeginnerLinkly · Project 1 of 12 ~3h· 5 milestones

Scope it and size it with real capacity math

Someone slides a one-line ticket across the table: 'build a URL shortener.' No numbers, no diagram, no idea whether this needs to survive one server or one hundred.

back-of-the-envelope estimationfunctional vs non-functional requirementsQPS and traffic modelingcapacity planningstorage sizingkeyspace and collision mathorder-of-magnitude sanity checkssystem design interview framing
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A one-page requirements doc (functional and non-functional) plus a completed estimation sheet with real QPS, storage, and keyspace numbers, defensible enough to open a whiteboard with on rung 2.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

requirements-template.mdmarkdown
# Linkly - Requirements (fill this in first, before any diagram)

## Functional requirements (in scope for v1)
1. 
2. 
3. 

## Explicitly out of scope for v1
- 
- 

## Non-functional requirements
- Availability target: 
- Latency target (p99): 
- Consistency model: 
- Scale horizon:

Reading this file

  • ## Functional requirements (in scope for v1)Write these as things a PM would nod along to, one sentence each.
  • ## Explicitly out of scope for v1This list stops scope creep as hard as the in-scope list defines the product.
  • - Availability target: Non-functional requirements need numbers attached, not adjectives like 'reliable'.

Fill this in first. If you catch yourself sketching boxes before this is done, stop and come back here.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Turn the vague ask into functional requirements

    4 guided steps

    Without a functional scope, sizing is a guessing game and the diagram you eventually draw has nothing to justify it. This is the step almost everyone skips.

  2. 2

    Pin down non-functional requirements and SLAs

    4 guided steps

    Non-functional requirements are what later rungs get graded against. 'Fast and reliable' can't be tested, '99.9% uptime, p99 under 100ms' can.

  3. 3

    Calculate traffic: writes/day, read:write ratio, QPS

    4 guided steps

    QPS is the number that determines whether one server can handle this at all, and the read:write ratio is exactly what motivates the read scaling rung 3 does next.

  4. 4

    Size 5-year storage and the short-code keyspace

    4 guided steps

    Storage math is where estimates go wrong by orders of magnitude, usually from mixing bytes/KB/MB/GB or days/years. Getting it right also tells you exactly how long a short code has to be.

  5. 5

    Estimate bandwidth and assemble the final estimation sheet

    4 guided steps

    This is the artifact you actually carry into rung 2, and it's what proves, in numbers, exactly which bottleneck the next rung needs to fix.

What's inside when you start

3 starter files, ready to clone
5 guided milestones
5 full reference solutions
8 code blocks explained line-by-line
5 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

Completed requirements-template.md with a numbered in-scope functional list, an explicit out-of-scope list, and non-functional targets (availability, latency, consistency, scale horizon)
capacity_calc.py run with real assumptions, producing average and peak QPS, 5-year storage, and short code keyspace numbers
Fully filled-in estimation-sheet-template.md with all eleven metrics plus a two-sentence scale story
A one-paragraph explanation of why 1,000,000 writes/day at a 100:1 read:write ratio forces read scaling before anything else

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building