Back-of-the-Envelope Estimation

A number should be able to overturn the design

Suppose you have clarified the requirements for a collaborative editor and drawn an application service, a database, and a cache. The interviewer gives you two million daily users. You divide by the number of seconds in a day, announce a requests-per-second figure, and return to the diagram.

What has the calculation accomplished? If the same boxes remain, with the same responsibilities and the same deep dive, perhaps nothing.

Estimation earns its time when it can overturn a design decision. It might show that inbound traffic is ordinary but downstream fan-out is not; that object bytes dominate metadata; that the median tenant is harmless but one hot key is not; or that keeping an unbounded operation log will cost more than serving the live workload. The result need not be precise. It must be consequential.

In an interview, begin by naming the decision at risk:

I want to find out whether live edit propagation, durable history, or a hot document should shape this architecture. I’ll estimate those paths and stop when the first deep dive is clear.

That sentence makes the assumptions negotiable and the arithmetic finite.

Count work, not product nouns

“Two million users” is not yet a load. A user may open the product once a week, hold a connection all day, upload a video, or trigger thousands of deliveries with one action. Follow the operations that consume a constrained resource.

For an interactive system, separate reads from writes when they have different costs or correctness boundaries. For messaging, feeds, notifications, and collaboration, count the work caused by each write. For file and media systems, payload size and data movement often say more than request count. For logs, metrics, and audit systems, ingest rate, retention, indexing, and query windows deserve attention. For booking or inventory, low traffic can still create high contention around one scarce item.

Concurrency also needs a reason. It matters when connections, sessions, locks, streams, or shared state remain live. It is usually a distraction for short, independent HTTP requests. Cache size becomes worth estimating only after you can name a reusable hot set and an acceptable freshness rule. Estimating every familiar dimension is another form of avoiding the design.

Most prompts need three or four quantities. Choose them from the requirement most likely to become expensive:

• operations per second for the dominant read and write paths;
• peak, burst, or skew relative to the daily average;
• downstream fan-out or write amplification;
• concurrent connections or active shared sessions;
• payload bandwidth;
• raw data growth, retention, indexes, replicas, and derived copies;
• the hot set that could plausibly live in memory; or
• queue growth when arrival temporarily exceeds service.

The unit belongs in every result. “A billion” cannot constrain a system until it becomes a billion events per day, bytes retained, recipients per broadcast, or dollars per year.

Keep average, peak, burst, and skew separate

Average load helps establish the ordinary path. It is not a capacity plan. Traffic may concentrate in a workday, jump during a launch, retry after a dependency recovers, or converge on one tenant while the rest of the fleet is quiet.

Use four different questions:

1. What work arrives over an ordinary day?
2. How much of it arrives in the busiest sustained period?
3. What short event or recovery can exceed that peak?
4. Which key, tenant, room, object, or account is much larger than the median?

The exact peak multiplier should come from product behavior when possible. If it is unknown, state a provisional multiplier and expose its weakness: “I’ll use five times the daily average for a workday product. If usage follows a scheduled event or reconnect storm, that assumption is too low and I’ll need a burst case.”

A few round conversions are enough for interview arithmetic:

1 day ~= 100,000 seconds
1 million operations/day ~= 10 operations/sec on average
100 million operations/day ~= 1,000 operations/sec on average
1 billion operations/day ~= 10,000 operations/sec on average

1 KB * 1 million items ~= 1 GB
1 MB * 1 million items ~= 1 TB

These are scale markers, not measurements. Round to one useful digit, keep the units visible, and do not hide a sensitive assumption behind precise division.

Follow one workload through the system

Consider collaborative document editing for teams. Users must see one another’s edits promptly, reconnect without losing acknowledged work, and recover recent versions. Cursor and presence updates may be ephemeral. Older operation history may be compacted into snapshots.

Assume, provisionally:

• two million daily active users;
• ten percent active in the busiest sustained period, or 200,000 editors;
• one edit operation from each active editor every three seconds;
• three other connected collaborators on a typical live document;
• about 300 bytes per encoded edit before transport and storage overhead; and
• thirty days of raw operations before compaction.

These numbers are fictional inputs to the design exercise, not a forecast. The candidate should invite correction, especially on active concurrency and edits per second, because they dominate the result.

The live path

At peak, the collaboration tier receives roughly:

200,000 active editors / 3 seconds ~= 70,000 edit operations/sec

That rate is substantial, but a fleet can partition it by document or workspace. The more revealing calculation follows the write. With roughly three recipients per operation:

70,000 operations/sec * 3 recipients ~= 200,000 outbound messages/sec

The durable store should not perform a synchronous write for every recipient. Active-document processes can broadcast from memory while each accepted edit is appended once to durable history. Cursor and presence updates can be coalesced because their value expires quickly.

Payload bandwidth gives the result proportion. At 300 bytes per message, the application payload is about 60 MB/sec before protocol overhead. This is real traffic, but it does not yet look like the governing problem. Connection management, ordering within a document, and fan-out are stronger candidates for the deep dive. A media workload with megabyte payloads would reverse that judgment.

The history path

Peak traffic should not be multiplied across a whole day as though the peak never ends. Suppose the ordinary daily average is 10,000 accepted edit operations per second. Then:

10,000 operations/sec * 100,000 seconds/day ~= 1 billion operations/day
1 billion operations/day * 300 bytes ~= 300 GB/day raw

Thirty days of raw operations is about 9 TB. Three replicas make that roughly 27 TB before indexes, metadata, checksums, and snapshots. The calculation does not select a vendor or dictate an exact disk count. It does make retention and compaction part of the architecture. A design that keeps every operation forever in its serving store now owes an explanation.

The replicas are not free capacity. They buy durability or read placement while multiplying storage and write traffic. Search indexes, analytics copies, and backups should be named separately because each has its own lag, repair, and deletion obligations.

The impaired path

Queue depth is not an independent guess. It grows from a mismatch between arrival and service. If a regional impairment leaves delivery workers able to send 150,000 of the 200,000 outbound messages each second for thirty seconds, the backlog grows by approximately:

(200,000 - 150,000) messages/sec * 30 sec = 1.5 million messages

Now the design needs a bounded buffer, backpressure, and a recovery policy. Whether 1.5 million messages is safe depends on their encoded size, the queue’s retention and replication, and how quickly recovery traffic can drain without causing a second overload. “Add a queue” is not the conclusion; the useful question is what the queue permits the system to survive.

Break the median design

The typical edit has three recipients. The interviewer now asks about a document with 1,000 active editors.

At one edit every three seconds per editor, that single document receives about 300 edit operations per second. Broadcasting each operation immediately to every other editor would approach 300,000 outbound messages per second from one coordination key—more than the estimated delivery load for the rest of the ordinary fleet.

The average concealed the architecture’s most difficult boundary. Adding machines does not automatically divide one ordered document. The design may need dedicated placement for a hot document, a hierarchical broadcast path, coalesced cursor and presence updates, rate limits on low-value signals, and a careful account of which operations require a common order. This is where an estimation chapter becomes a systems chapter: the number exposes a policy and coordination problem, not merely a capacity total.

Sensitivity is the final check. Ask which assumption, if multiplied by ten, would change a boundary. Ten times the number of ordinary documents may call for more partitions. Ten times the collaborators on one document may invalidate the partitioning unit itself. Those are different design changes, even if both increase the same fleet-wide message count.

Know when the answer is “not yet”

Some estimates require facts you do not have. Node count needs a benchmark or at least a credible per-node throughput range. Cache memory needs the hot-set cardinality, object size, and freshness policy. Cost needs a deployment model and unit prices. Cross-region bandwidth needs placement and replication behavior.

Do not invent these facts to make the exercise look complete. State what the unknown would decide and continue with a threshold:

I cannot size the cache from total documents. If the active set for the busiest hour is about 200,000 documents and the cached collaboration state is 50 KB each, that is roughly 10 GB before overhead and is plausible across a small cache tier. If active state is measured in megabytes or must be duplicated across regions, I would revisit the state representation and placement.

The threshold is useful because it can be tested later. False precision only turns an assumption into an invisible dependency.

When arithmetic drifts, recover in the same way: restate the unit, round the calculation, and reconnect it to the choice. A corrected estimate that changes the design is stronger than a flawless calculation with no consequence.

Rehearse the branch, not the formula sheet

Practice estimation by forcing each result to choose a path:

1. For a feed or notification system, estimate one inbound write and its downstream work for an ordinary account and a hot account. Decide where synchronous work must end.
2. For file sharing or video, estimate metadata requests and byte transfer separately. Decide whether application servers should carry object bytes and where locality or a CDN begins to matter.
3. For metrics or audit logs, estimate raw daily ingest, retention, replicas, indexes, and one derived view. Decide when compaction, downsampling, or cold storage becomes necessary.
4. Return to a completed design and multiply one assumption by ten. Identify the earliest boundary that becomes false; “use more machines” is not enough.

Review the result with four questions:

• Did I name the decision before calculating?
• Did each result retain its operation and unit?
• Did I distinguish average, sustained peak, burst, and skew where relevant?
• Can I point to the boundary, policy, or deep dive that changed?

If the last answer is no, the estimate is unfinished even when the arithmetic is correct.

Field reference

ESTIMATION PASS

DECIDE
What architecture choice could this estimate overturn?

FOLLOW THE WORK
Operation rate -> fan-out -> payload -> retained state -> derived copies

CHECK SHAPE
Average; sustained peak; short burst; hot key or tenant

KEEP HONEST
State the horizon, operation, unit, and sensitive assumption.
Separate raw data from replicas, indexes, backups, and derived views.
Queue growth = (arrival rate - service rate) * duration.

TEST THE BRANCH
What changes at 10x? More partitions, or a different boundary?

STOP
The risky path is visible and the next design decision is clear.

Estimation is complete when it has made the design narrower. In the example, ordinary edit traffic supports document partitioning, retained history demands compaction, delivery impairment demands backpressure, and the hot document challenges the partitioning boundary. The next chapter turns those pressures into operation contracts, owned facts, and storage choices.

Related reading: Requirements and Non-Functional Requirements supplies the promises that estimates must obey. Observability, Performance, and Cost develops measurement and capacity reasoning, while Scaling and Partitioning examines the boundaries that pressure may force apart.