Estimation cheat sheet: practical reference values

TL;DR

• Use the sheet as a set of order-of-magnitude anchors, not as a list of guaranteed hardware limits.
• Convert the prompt into requests/sec, bytes/sec, and storage over a stated time horizon; then connect each result to a design decision.
• Keep units explicit: distinguish bits from bytes and decimal units from binary units.
• State the workload, hardware, network path, peak multiplier, and cache assumptions before using any number.
• Validate a consequential estimate with a benchmark, a provider's current documentation, or production measurements.

Why this framework matters

Back-of-the-envelope estimates are useful when the architecture depends on relative cost or scale. A latency order of magnitude can justify keeping data in memory, a storage calculation can separate metadata from media, and a throughput estimate can show whether one process or a distributed tier is a plausible starting point. The value is the decision that follows the number, not the memorization of a precise constant.

When to use this framework

Use this sheet during the estimation and capacity-planning parts of a system-design exercise, or when comparing architecture options in a design review. It is most useful for early sizing, identifying the dominant resource, and choosing what to benchmark next. It is not a substitute for workload-specific testing, current provider pricing, or an availability and failure analysis.

Step-by-step method

1. Choose the dominant quantity. Start with request rate, storage growth, bandwidth, or latency—the quantity most likely to change the architecture.
2. Write the units. Convert users and daily actions into requests/sec, payloads into bytes/sec, and object sizes into storage over a stated horizon.
3. Round deliberately. Use powers of ten for mental math, and say what was rounded.
4. Compare with an assumption. Use the reference values below only as an illustrative starting point; actual capacity depends on workload and configuration.
5. Make the decision and check the failure path. Identify the component, headroom, peak behavior, cache miss behavior, and what must be measured before implementation.

Reference values

Latency numbers (approximations)

These are practical mental anchors for order-of-magnitude reasoning. They are not tied to a particular benchmark or hardware generation.

Useful ratios to remember:

• Memory is ~1000× faster than SSD for sequential reads
• SSD random I/O is tens to roughly 100× faster than HDD random I/O, depending on the devices
• Same-datacenter network paths are usually much faster than cross-region paths; the ratio depends on the route

Powers of 2 (binary storage reference)

Day to seconds: 86,400 ≈ 10^5 = 100K seconds/day

In interviews, round aggressively:

• 1 billion ≈ 10^9
• 1 million ≈ 10^6
• 1 trillion ≈ 10^12

Throughput rules of thumb

Use these as placeholders for interview arithmetic only. Query complexity, durability settings, data size, concurrency, and implementation determine the measured capacity.

Database:

• A single PostgreSQL primary: ~5k-20k reads/sec (depends on query complexity and index efficiency)
• A single PostgreSQL primary: ~1k-5k writes/sec (depends on WAL flush settings)
• A Redis instance: ~100k-500k ops/sec

Network:

• Typical server NIC: 1-10 Gbps = about 125 MB/s to 1.25 GB/s
• HTTP overhead per request: ~300 bytes minimum (headers)
• gRPC can reduce per-request overhead through binary framing and header compression, but the result depends on the protocol and payload.

Storage:

• HDD sequential: ~200 MB/s
• SSD (SATA): ~500 MB/s
• SSD (NVMe): ~3,500 MB/s
• Memory: ~50 GB/s

Size estimates for common data types

The sizes below are illustrative payload assumptions; encoding, compression, metadata, indexes, and storage overhead can change the result substantially.

Worked example: photo sharing

The following is an illustrative example. Assume 100M daily active users, each uploading 2 photos/day on average, and an average compressed photo size of 3MB. Replace the assumptions with the prompt's workload.

Storage per day:

100M users × 2 photos × 3MB per photo = 600M MB = 600 TB/day

Implication: object storage rather than a relational database. If an illustrative price of $0.023/GB/month were used:

600 TB/day × 30 days = 18 PB/month
18 PB × $0.023/GB = 18,000,000 GB × $0.023/GB = $414,000/month in storage alone

Use a lifecycle policy to move older media to a colder storage tier when the retention and access requirements allow it. Current provider pricing and retrieval charges determine whether that saves money.

Writes per second:

100M users × 2 uploads / 86,400 seconds = ~2,300 uploads/sec

The upload path can use a worker fleet sized from measured processing time plus direct-to-object-storage uploads with short-lived authorization (a valet-key pattern), which reduces application-server bandwidth.

Reads per second (assuming 10 photo views per user per day):

100M × 10 / 86,400 = ~11,500 reads/sec

If an illustrative 90% cache hit rate holds, about 1,150 requests/sec miss the CDN and reach the origin. CDN and origin egress pricing still needs to be included; it is not zero by default.

Database (storing photo metadata):

100M × 2 photos × 300 bytes metadata = 60 GB/day new metadata

The metadata is far smaller than the media, but 60GB/day still requires retention, partitioning, indexing, backup, and write-throughput planning. Whether it fits in one relational deployment depends on those requirements and measured capacity.

Trade-offs, limitations, and failure modes

Reference numbers make mental math faster, but false precision can produce the wrong architecture. Latency varies by locality and connection reuse; throughput varies by query shape, durability, concurrency, and data size; storage estimates omit overhead unless you add metadata, indexes, replicas, backups, and retention; and cost estimates change with region, egress, discounts, and access tier.

Always separate average from peak load and model what happens when a cache misses, a queue replays, a replica lags, or an origin loses capacity. The example's object-storage and CDN choices also trade database relief for egress cost, cache invalidation, and origin-protection work. Use the sheet to choose the next measurement, not to claim that a component is safe at a particular number.

Interview application

30-second answer

"I use the cheat sheet as an order-of-magnitude aid. I start with the dominant quantity, keep units explicit, convert users into requests or bytes per second, and state the peak and payload assumptions. Then I compare the result with a clearly labeled working capacity, make the architecture decision it supports, and call out what must be benchmarked or protected during failure."

5-minute explanation

"First I choose whether traffic, storage, bandwidth, or latency is most likely to change the design. I write the formula and units, round to powers of ten, and separate average from peak. For traffic I use users times actions per day divided by seconds per day; for storage I multiply object size by volume over a stated retention horizon; for bandwidth I multiply request rate by payload size and convert bits and bytes correctly.

"Next I compare the order of magnitude with an illustrative component capacity and say what follows: object storage for large media, a cache or CDN for hot reads, more workers for upload or queue processing, or a different data layout for write pressure. I include overhead and failure amplification, label all assumptions, and finish with a benchmark or measurement plan."

Test Your Understanding

Use these short prompts to practice the conversion and the decision that follows it.

Recap

1. Use latency tiers and throughput ranges as illustrative anchors; ratios and bottleneck direction matter more than exact numbers.
2. Distinguish binary units (KiB, MiB, GiB, TiB) from decimal units, and use ~86,400 ≈ 10^5 seconds per day for mental math.
3. Treat database and Redis ranges as workload-dependent placeholders, not universal scaling thresholds.
4. For read/write rate estimation: start with DAU × average operations per day, divide by 86,400 to get per-second rate. Add a 2-3× peak multiplier for traffic spikes.
5. Let the numbers guide decisions: 600 TB/day upload points to object storage; 2,300 uploads/sec points to an upload-processing plan; 11,500 reads/sec requires an origin and delivery capacity analysis, often including a CDN.

Related Concepts

• Estimation - Applies these reference values in a complete traffic, storage, and bandwidth workflow.
• Capacity Planning - Turns order-of-magnitude estimates into component sizing and scaling boundaries.
• Interview Timing - Helps keep estimation short enough to inform the rest of the design.
• Scalability - Explains the scaling strategies selected after a capacity comparison.