A Capacity-Assumption Worksheet for System Design Interviews

TL;DR

• Use capacity estimates to justify system-design decisions, not just to display arithmetic.
• Define the unit of work, separate stated facts from assumptions, and distinguish average demand from peaks.
• Connect storage to retention and test which architectural choices change when an assumption changes.

The estimate should support a decision

System design interviews can turn into arithmetic performances: large user counts, quick multiplication, and architecture boxes added before anyone explains what the numbers change. A capacity-assumption worksheet keeps the estimate connected to the design. It records what is known, what you assumed, and which decision depends on the result.

This is an illustrative interview exercise, not production sizing advice or a benchmark of any infrastructure service. Real capacity planning needs workload measurements, testing, and operational constraints. In a mock interview, the worksheet helps a reviewer inspect your reasoning without pretending the starting numbers are certain.

Related reading: How to Prepare for System Design Interviews: A Complete Guide (2026).

Start with the unit of work

Define what one request or event means. A daily active user is not the same as a request, and an uploaded object is not the same as a byte. Before multiplying, identify the activity you are sizing and the time window involved.

For a hypothetical notification service, distinguish messages created, delivery attempts, and status events. A single logical message may produce more than one attempt or event. Do not assume those counts are identical merely because the initial question uses the word “message.”

Write the unit beside every number. “Two hundred thousand” is incomplete; “two hundred thousand logical messages per day” can enter a calculation. Units help you notice when a formula mixes daily totals with per-second rates or raw data with retained storage.

Separate givens from assumptions

Use four columns: value, unit, source, and confidence. The source can be interviewer-provided, explicitly assumed, or calculated from other rows. Do not let a number migrate from assumed to known as the conversation continues.

In an illustrative case, suppose the interviewer gives two hundred thousand messages per day. You might assume an average payload size for the exercise, but that assumption must be stated and open to revision. Ask whether attachments or large metadata are in scope before treating one small payload size as representative.

Keep uncertain factors as ranges where that aids the decision. You do not need a false decimal precision. If both ends of a plausible range lead to the same architecture choice, say so. If the choice changes, identify the measurement you would seek next.

Distinguish average load from concentrated demand

Dividing a daily total by the number of seconds in a day gives an average rate under that simple model. It does not describe a launch event, a batch import, or a morning concentration of activity. State how you are representing peak demand and why.

Use an explicit hypothetical peak factor only as a discussion assumption. Do not claim it is an industry standard without evidence. Ask what creates the burst and whether work can be queued. A workload that tolerates delayed processing may lead to a different design from one requiring an immediate response.

Also identify retry behavior and failure recovery as separate sources of work. Avoid adding an arbitrary multiplier and moving on. Explain which failure scenario could produce extra attempts and what design choices would bound or absorb that work.

Connect storage estimates to retention

A daily data volume becomes a storage estimate only after you decide what is retained and for how long. Separate raw payloads, indexes, derived records, and any replicated copies in your reasoning. You do not need exact vendor overhead figures to recognize that one raw-byte calculation is not a complete system footprint.

For the interview exercise, write the retention assumption explicitly. If a changed requirement doubles the retention period, show which rows change and which do not. This demonstrates that the estimate is a model rather than a number you memorized.

Include deletion or archival behavior as a question when relevant. A requirement to retain an audit history differs from a requirement to keep message bodies. Do not silently preserve all data forever because it makes the arithmetic simpler.

Rehearse a sensitivity follow-up

After producing the first estimate, ask a practice partner to change one important assumption. What if traffic arrives in a short burst? What if payload size varies widely? What if status events must be retained longer than content? Update the worksheet before redrawing the architecture.

Explain whether the changed estimate affects queueing, partitioning, storage policy, or the need for measurement. Avoid adding technology names without a causal connection. A strong answer says which constraint changed and why that makes the previous design less suitable.

Phantom Code AI's mock-interview workflow provides a technical practice context to consider. Keep the worksheet as your own artifact and verify calculations independently. A generated follow-up or confident response is not a substitute for checking units and arithmetic.

Review the explanation, not just the final number

Ask a reviewer whether they could reconstruct your estimate from the stated assumptions. Could they identify the most uncertain input? Could they see why the result mattered? These questions reveal more about the quality of the answer than whether your final number resembles a sample solution.

When comparing practice tools through the AI interview software guide, look for feedback that challenges assumptions and decisions rather than merely praising a familiar architecture. Your goal is a defensible model you can revise under questioning.

End the exercise with a short list of measurements you would gather before production implementation. That boundary demonstrates judgment. An interview estimate should make uncertainty manageable and design choices explainable; it should not disguise an assumed workload as a tested capacity guarantee.