8. Project: Enlace's capacity table

Description

This is the module's capstone: the moment you stop computing one number at a time and produce, from scratch and on your own, the complete capacity table for Enlace. Starting only from the scale —the prompt's anchor numbers— you'll derive the four capacity numbers (QPS, storage, bandwidth, memory), with their average and peak variants, with indexes and replicas where appropriate, each calculation run in Python, one sanity check per row, and a note of assumptions. The deliverable is what you'd bring to a design whiteboard or an interview: a defensible table that summarizes, in five rows, the capacity of the whole system.

There's no new topic here. Everything you need you learned in lessons 2 to 7: the tools (powers of 10, seconds per day, units), the four calculations (one per lesson), and the rounding and verification discipline of lesson 7. This project is the assembly: putting the pieces together into a single coherent artifact, with the rigor that each number is computed (not quoted), rounded with judgment, crossed with a sanity check, and comes with its assumptions stated. By the end you'll have Enlace's capacity table and —more important— the method to produce that of any system from its scale.

Connection to the module: this lesson closes the module by putting everything together. Each row of the table is a lesson: QPS (3), storage (4), bandwidth (5), memory (6); and the discipline that makes it trustworthy is lesson 7. The table you assemble here is the one Enlace carries with it for the rest of the guide: in module 3 it will justify the data model and why 7 base62 characters suffice; in module 4, the cache (the 333 MB working set and the hit ratio); in module 5, the replicas and sharding decision (the 6/27 TB and the 12,000 peak reads/s); in modules 6 and 7, the balancing and the tradeoffs. The module's boundary holds to the end: here we estimate, we don't design. The table produces the numbers the design decisions will use; it doesn't make those decisions.

The load plan before building

Before a structural engineer erects a building, they produce a load table: how much weight each column supports, how much wind force the façade withstands, how many people fit per floor according to the code. It's not the building —it doesn't have a single wall drawn yet— but it's what decides whether the building is even possible and how big its beams should be. A plan made without that table is a pretty fantasy that collapses; the load table is what turns the drawing into something that can be built and defended before the inspector.

The capacity table is exactly that for a system. It's not the design —it doesn't have boxes or arrows yet— but it's what says whether the system fits in one server or a hundred, whether the network holds up, whether a cache is worth it, whether the database has to be spread out. A design made without a capacity table is over-engineering or undersizing disguised as architecture; the table is what anchors each later decision to a number you can justify. That's why this project goes at the end of the estimation module and before the design modules: you produce the load plan first, and with it in hand, modules 3 to 7 draw the building with judgment.

And like the engineer before the inspector, the proof that your table is useful is that it withstands questions. "Why a cache?" → "because it's 4,000 reads/s and growing and the working set fits in 333 MB of RAM". "Why no sharding?" → "because 6 TB fits on one server; the QPS is resolved by the cache". Each answer is a row of the table. That's what you're going to build.

The assignment

You're given Enlace's scale and nothing else. Produce the complete capacity table.

The scale (the anchor numbers, identical throughout the guide):

• 100 million new URLs per month.
• read:write ratio = 100:1.
• Retention: 5 years. Average long URL: ~500 bytes; complete record: ~1 KB.
• Peak factor to assume: 3x (within the 2–3x range for web services).

What you must deliver:

1. The capacity table, with these five rows, each number computed (not quoted):
   • QPS — write and read, average and peak.
   • Storage — raw at 5 years, with indexes, and provisioned with replicas.
   • Bandwidth — write and read, average and peak; monthly egress.
   • Memory — the working set (hot 20%) and its relationship with the total on disk.
   • Derived — servers for the peak and concurrency (Little's Law).
2. A note of assumptions: each assumption that holds up the table (30-day month, 3x peak factor, +50% index, ×3 replica, 500 B cache entry, etc.).
3. A sanity check per row: the expected mark and a reference that validates the number.

Try to do it yourself before looking at the solution. Open python3, type the calculations, round to one significant figure, and assemble the table. The complete solution —with the script run— is below.

Guide: the assembly order

The numbers chain together, so there's a natural order that avoids recomputing. Follow it:

1. QPS first, because almost everything else depends on it. Write (100M/month ÷ seconds/month), then read (× ratio), then peak (× factor). Round here: the rounded numbers (40, 4,000) are the ones that feed the following rows.
2. Storage, which doesn't depend on the QPS but on the prompt directly (records × retention × size), plus the index and replica factors.
3. Bandwidth, which reuses the QPS (QPS × payload) for write and read, average and peak, plus the monthly egress.
4. Memory, which reuses the new URLs per day (derived from the write QPS) for the working set (20% × 500 B).
5. Derived at the end: servers (peak QPS ÷ capacity per server) and concurrency (Little's Law).

With that order, each row uses numbers you already computed, and you don't repeat work. Now, the solution.

Solution

# ENLACE'S CAPACITY TABLE — from the scale to the numbers, all computed.

# --- ANCHOR NUMBERS (the prompt, the only thing given) ---
urls_per_month   = 100_000_000     # 100M new URLs/month
read_write_ratio = 100             # read:write = 100:1
retention_years  = 5               # retention
url_bytes        = 500             # average long URL (payload and cache entry)
record_bytes     = 1_000           # complete record ~1 KB (on disk)
peak             = 3               # peak factor (2-3x range)
sec_month        = 30 * 24 * 3600  # 2,592,000 s/month
sec_day          = 86_400          # s/day

# --- ROW 1: QPS (rounded here; the following rows start from the rounded) ---
qps_write = round(urls_per_month / sec_month, -1)      # 38.58 -> 40
qps_read  = round(qps_write * read_write_ratio, -3)    # 4000
print(f"[QPS]        write ~{qps_write:.0f}/s avg, ~{qps_write*peak:.0f}/s peak | "
      f"read ~{qps_read:.0f}/s avg, ~{qps_read*peak:.0f}/s peak")

# --- ROW 2: STORAGE (records x retention x size, + indexes + replicas) ---
records  = urls_per_month * 12 * retention_years
raw      = records * record_bytes
print(f"[STORAGE]    {records/1e9:.0f}e9 records | raw {raw/1e12:.0f}TB, "
      f"+idx {raw*1.5/1e12:.0f}TB, +repl x3 {raw*1.5*3/1e12:.0f}TB")

# --- ROW 3: BANDWIDTH (QPS x payload) ---
write_bw     = qps_write * url_bytes
read_bw      = qps_read * url_bytes
egress_month = read_bw * sec_day * 30
print(f"[BANDWIDTH]  write {write_bw/1e3:.0f}KB/s avg, {write_bw*peak/1e3:.0f}KB/s peak | "
      f"read {read_bw/1e6:.0f}MB/s avg, {read_bw*peak/1e6:.0f}MB/s peak | egress {egress_month/1e12:.1f}TB/month")

# --- ROW 4: MEMORY (working set = hot 20% of the distinct URLs/day) ---
new_urls_day = urls_per_month / 30
working_set  = new_urls_day * 0.20 * url_bytes
print(f"[MEMORY]     WS = 20% x {new_urls_day/1e6:.1f}M URLs/day x {url_bytes}B = {working_set/1e6:.0f}MB "
      f"({raw/working_set:,.0f}x smaller than the disk)")

# --- DERIVED: servers (peak / capacity) and concurrency (Little's Law) ---
servers = qps_read * peak / 2000
conc    = qps_read * peak * 0.010      # 10 ms per request
nic     = 1e9 / 8 / 1e6                # 1 Gbps NIC in MB/s
print(f"[DERIVED]    servers ~{servers:.0f} (+1={servers+1:.0f}) | concurrency ~{conc:.0f} | "
      f"read peak = {read_bw*peak/1e6/nic*100:.1f}% of a 1Gbps NIC")

[QPS]        write ~40/s avg, ~120/s peak | read ~4000/s avg, ~12000/s peak
[STORAGE]    6e9 records | raw 6TB, +idx 9TB, +repl x3 27TB
[BANDWIDTH]  write 20KB/s avg, 60KB/s peak | read 2MB/s avg, 6MB/s peak | egress 5.2TB/month
[MEMORY]     WS = 20% x 3.3M URLs/day x 500B = 333MB (18,000x smaller than the disk)
[DERIVED]    servers ~6 (+1=7) | concurrency ~120 | read peak = 4.8% of a 1Gbps NIC

Common mistakes

Delivering figures without conclusions (a table that doesn't communicate). What happens: someone produces the five rows of correct numbers but stops there, without the "what each one means" column, and whoever reads it has the data but not the design. Why it happens: computing feels like the work, and translating the number into a decision seems like an extra. How to detect it: if your table is a list of values without a conclusion per row, you delivered half. How to fix it: each number ends in a decision ("~4,000 reads/s → calls for cache and replicas"), never in itself. The useful table doesn't say "the read QPS is 4,000"; it says "it's 4,000, so cache". The number is the means; the conclusion is the deliverable.

Not stating the assumptions (a table that can't be audited). What happens: the person delivers "27 TB" without saying they assume +50% indexes, ×3 replica, and zero expiration, and when someone asks "and if they expire at 2 years?" they can't answer because they don't know what they assumed. Why it happens: the assumptions are taken by default and forgotten once the calculation is done. How to detect it: if you can't list from memory each knob that holds up a number, you didn't state it. How to fix it: accompany the table with an explicit note of assumptions —each factor, each rounding, each assumed regime—. A table with stated assumptions is auditable and adjustable; one without them is a magic number that falls apart at the first follow-up.

Recomputing instead of chaining (ignoring that the numbers feed each other). What happens: someone goes back to the prompt for each row —divides 100M by the seconds again, re-estimates the URLs per day from scratch— instead of reusing the already-computed numbers, and along the way introduces inconsistencies (uses 40/s for the bandwidth but 38.58/s for the memory). Why it happens: the dependency graph between the numbers isn't seen. How to detect it: if the same number appears with two different values in different rows, you didn't chain; you recomputed with different roundings. How to fix it: follow the assembly order (QPS → everything else), fix the rounded value once, and feed it to the rows that depend on it. The bandwidth and the memory start from the same rounded QPS that the QPS reports; that way the table is internally consistent.

Exercises

Exercise 1 — Enlace grows 10×. The product takes off and now 1 billion URLs/month come in (10× the original scale), with all other assumptions equal. Recompute the table and say, row by row, which design conclusions change and which don't. In particular: does it still not need sharding for space? Is the network still plenty?

Exercise 2 — The expiration knob. The team decides that URLs expire at 2 years instead of being kept for 5. Which rows of the table change and which don't? Recompute the steady-state storage and say whether this alters the sharding decision.

Exercise 3 — Defend the design with the table. A colleague proposes, for the original Enlace (100M/month): "we have to shard the database into 10 nodes from day one, add a message queue for the writes, and put a global CDN for the bandwidth". Using only the capacity table, argue in three or four sentences why each of those three pieces is over-engineering for Enlace's scale, citing the number that disproves it.

Summary and next step

In this capstone you produced, from scratch and from the scale alone, the complete capacity table for Enlace: QPS (~40/~4,000 average, ~120/~12,000 peak), storage (6 TB raw · 9 with indexes · 27 with replicas), bandwidth (~2 MB/s read, ~5.2 TB/month egress), memory (working set ~333 MB, 18,000× smaller than the disk) and derived (~6–7 servers, ~120 concurrent connections). Each number you computed in Python, rounded to one significant figure, crossed with a sanity check, and accompanied with a note of assumptions that makes the table auditable. And you practiced the most important thing: reading the table as a design story —trivial write, read-heavy, manageable disk, plenty of network, profitable cache— and using it to defend what to build and what not.

Before closing the module you should be able to: produce the capacity table of any system from its scale, following the assembly order (QPS → everything else); accompany it with its assumptions and a sanity check per row; recompute it when an assumption changes (10× scale, expiration) knowing which rows move; and use it to dismantle over-engineering with the number that disproves it.

With this you close module 2. You have the tools (powers of 10, units), the four capacity calculations, the rounding and verification discipline, and the table that summarizes everything. Enlace stops being a vague prompt and becomes a system with defensible numbers. Module 3 takes those numbers and starts to design: the data model of the Link record, SQL vs. NoSQL for this case, and —the heart— the generation of the short_code: hash vs. counter+base62 vs. random, the base62_encode/decode function, and why 7 base62 characters suffice (62⁷ ≈ 3.5 × 10¹² codes, plenty for the 6 billion records this table projected). The estimation is over; the design begins, and it begins with the numbers you produced here in hand.

Resources

• The System Design Primer, "Back-of-the-envelope calculations" and the URL shortener exercise (Design Pastebin.com / Bit.ly) — github.com/donnemartin/system-design-primer. It walks through a capacity table almost identical to Enlace's, with the same QPS, storage, and bandwidth structure. The best free complement to this capstone; in English.
• Martin Kleppmann, Designing Data-Intensive Applications, Chapter 1 ("Reliability, Scalability, and Maintainability") — dataintensive.net. The conceptual framework for describing a system's load (throughput, percentiles, ratios) that underpins the whole capacity table. The guide's bedside book; in English.
• Alex Xu, System Design Interview – An Insider's Guide, chapter "Back-of-the-envelope estimation" and "Design a URL shortener" — summary and figures at bytebytego.com. It presents the estimation of a URL shortener step by step, with the same defensible-capacity-table spirit we assembled here. In English.