Project · Take Apart a System You Use Every Day

project

hard

module project

Ship something real. Submit your work when you're done.

Brief

Pick a system you personally use daily — a payment app, a food delivery app, a music service, your office chat tool — and produce the one-page design doc from task 8 for it, from the outside. Estimate its scale from public figures or defensible assumptions, name every component with the property it buys and the cost it charges, then run it through all six pressures. The document succeeds when a reader who knows the product can disagree with a specific line of your arithmetic rather than with your design in general, and when section 9 names at least three things that survive a 100x traffic increase, each correctly labelled contract, algorithm or deployment.

Deliverables

design.md — the one-page doc, all nine sections filled, body fitting on one printed A4 page at 11pt.
estimates.py — a runnable script in the shape of the task 3 envelope, printing DAU, read rps, write rps, bytes per day and a monthly cost line in both USD and INR. Every number in section 3 must come from this script.
assumptions.md — every assumption the script uses, each with its source (a public figure, an app-store download count, an annual report) or an explicit stated guess.
pressures.md — the six stress blocks in full Scale / Bottleneck / Decision / Tradeoff / Incident / Outcome form, expanded from the one-line versions in section 8.
A 300-word critique of your own doc naming the single weakest assumption and what you would measure first to replace it.

How we grade it

Every number in section 3 is reproducible: a reader running estimates.py with the stated assumptions gets the same figures to within rounding, and each has a named derivation chain.
Every component in section 6 carries exactly one sentence naming both the property it buys and the cost it charges; a component with only one half of that pair, or neither, is absent from the list.
All six pressure blocks name a single specific first bottleneck (a named component or resource), not a general area, and each has a non-empty tradeoff line.
Section 9 lists at least three things that do not change at 100x, each labelled contract, algorithm or deployment, with a one-sentence reason; at least one is a contract and at least one is an algorithm.
The doc body fits on one side of A4 at 11pt with all nine sections present; the arithmetic appendix and the other files may overflow.

Hints

Pick a product you use, not one you admire — you need the intuition for how often you actually open it, because that number drives everything else.

For scale, chase two public figures and derive the rest: monthly actives from an earnings call or a press release, and app-store download counts. A DAU-to-MAU ratio between 0.2 and 0.5 covers most consumer products; below 0.1 is a utility you open when you need it, above 0.5 is a habit. If you cannot find any figure, say so and pick a number you are willing to defend.

The fastest way to get section 6 wrong is to list components from memory. Instead, trace one real user action end to end — open the app, see a screen, tap once — and add a component only when the trace needs it. Most people find their honest list is five or six boxes, not twelve.

Section 9 is where this project is actually graded, and it is the hardest section because it rewards restraint. Good candidates: an ordering guarantee, a uniqueness constraint, an idempotency key format, a ranking function, a hashing scheme, a settlement invariant. Bad candidates: it still uses HTTP, it is still written in Go. If the thing you named would survive because nobody would bother changing it, that is not the same as surviving because the pressure does not land on it.

If a pressure genuinely does not apply — a purely local tool has no meaningful residency story — write one line saying why rather than inventing a problem. Saying not applicable, because the data never leaves the device is a correct answer and takes courage.

Expected output

$ python estimates.py system: <the app you picked> MAU 180,000,000 (Q-report, investor deck) DAU 72,000,000 (0.40 DAU/MAU, assumption) opens/user/day 4.2 (assumption, defended) reads/day 907.2 M writes/day 14.4 M read:write 63 : 1 avg read rps 10,500 peak read rps 31,500 (3x) avg write rps 167 bytes/day 2.9 TB ------------------------------------------------ egress / month $61,200 / Rs 53,85,600 blob storage / month $24,300 / Rs 21,38,400 $ wc -w design.md 780 design.md # one page, nine sections $ grep -c '^- \[' design.md 4 # four labelled 'does not change' entries

Section 9 of a strong submission reads like this:

**9. What does NOT change at 100x.** - [contract] A message is delivered to a conversation at most once and is never reordered relative to others from the same sender. 100x more messages makes this harder to implement, not less true. - [algorithm] Per-conversation sequence numbers assigned by a single owner. The assignment is one increment whether it happens 10 times a second or 10,000; what changes is who owns the conversation. - [deployment] Everything else. Conversation ownership moves from one process to a sharded, leader-elected set. Both of the pressures above landed here, which is the expected result.

Stretch goals

Do a second doc for a competitor to the same product and diff the two. The sections that differ are the actual product decisions; the sections that match are the domain's fixed costs.

Find a public postmortem or engineering blog post about the system you picked and check your section 8 against it. Score yourself on how many first-bottleneck predictions you got right, and write one line on each miss.

Add a section 10 pricing the design: total monthly infrastructure in both currencies, divided by DAU, to get a cost-per-user-per-month figure. Compare it to the product's revenue per user if that is public. Systems where these two numbers are close are systems with interesting design constraints.

Rewrite section 3 for the same system as it existed at 1/1000th the scale, changing nothing else. Identify which components in section 6 would not have existed then, and which invariant in section 7 has been true since day one.

Hand your doc to someone who does not know the product and ask them to reconstruct the six pressures from sections 1 to 7 alone. Anything they cannot predict is a gap in the earlier sections, not in section 8.