← All sessions & projects
Project 1 · Due Fri 12 June · after Session 2

Project 1: Capacity Estimation Worksheet

A one-page worksheet that sizes one system and names the single number that decides its shape.

What this is

Prove a design fits, with numbers.

Pick a system and estimate the handful of numbers that decide whether it lives on one box or needs a fleet. The point is not precision, it is showing you can bound a problem before you build it.

💡 In plain English

Like working out how much food and how many tables you need before you book a venue. The numbers are rough, but they tell you whether you are planning a dinner party or a wedding.

Do this, in order

The steps.

  1. 1
    Pick a system you can describe in one sentenceA URL shortener, a group chat, an image host. Real or famous, your choice. Write that sentence down first.
  2. 2
    List your assumptions as labelled numbersDaily active users, actions per user per day, average item size, how long you keep data. Mark each one "(assumption)".
  3. 3
    Do the four estimates, showing the arithmeticTraffic (requests/sec), storage, bandwidth, and memory for the hot set. The working matters more than the answer.
  4. 4
    Apply a peak factorReal traffic spikes. Multiply average by 2–10× for peak and say which factor you chose and why.
  5. 5
    State the one bounding numberThe single figure that decides one-node vs fleet, and one sentence on what it means for the design.

Fill this in

The worksheet.

System
one sentence: what it does
Assumptions
DAU = __ · actions/user/day = __ · avg item size = __ · retention = __ (all guesses, labelled)
Traffic
__ DAU × __ actions ÷ 86,400s = __ avg req/s · × __ peak factor = __ peak req/s
Storage
__ items/day × __ bytes × __ days retention × __ replication = __
Bandwidth
__ req/s × __ bytes/payload = __ (in and out)
Memory
hot set ≈ __ → does it fit in one machine's RAM? yes / no
Bounding number
________ → therefore the architecture is ________

How it's marked

What good looks like.

✓ Strong submission

  • Every number is labelled as an assumption you could defend out loud.
  • The arithmetic is shown and the units are consistent throughout.
  • You designed for peak, not just average.
  • You end with one number and what it implies for the architecture.

✕ Common mistakes

  • Precise-looking figures with no stated assumptions behind them.
  • Sizing for average load and ignoring the spikes.
  • A wall of numbers with no conclusion.
  • Mixing bits with bytes, or per-second with per-day.

Wrapping up

Hand in the one-pager.

The filled-in template above is the whole deliverable. Keep it to a page. Bring questions to the next session.

Logistics
One page · the template is enough · due Fri 12 June.
submit on Maven
Stuck?
Use the latency + sizing numbers from Session 2. A defensible guess beats a blank.
rewatch S2
For the instructorHow to teach thisclick to open ▾

The talk-track for introducing and explaining this project to students, beat by beat.

  1. 1

    Introduce it warmly: "This is the gentlest project and the most important habit. You're not proving you can build the thing, you're proving you can size it before building." Reassure beginners: rough numbers are the goal, not precision.

  2. 2

    Explain the why: "Every strong design starts with a number that rules options in or out. This worksheet is that number, on training wheels." Tell them a famous system they can copy the shape of if they freeze.

  3. 3

    Walk the five steps slowly, they're the whole grade. The one students skip is labelling assumptions, so insist: "An unlabelled number looks like a fact you're claiming. A labelled one looks like an engineer thinking."

  4. 4

    Demo the template live with a real example (URL shortener is perfect). Fill one row per estimate out loud so they see the arithmetic, not just the result. Leave the filled example in the chat.

  5. 5

    Read the rubric as encouragement, not gatekeeping. The single biggest miss is "no conclusion", so hammer the last row: "If you don't end on one bounding number, you did sums, not estimation."

  6. 6

    Close on logistics and lower the stakes: "One page, due the 12th. I'd rather see honest guesses with working than a polished spreadsheet that hides them." Point them back to Session 2 if they stall.