Back-of-the-envelope estimation: a reproducible worked example

The goal is not a precise-looking infrastructure count. It is a reviewable chain from assumptions to units, architecture and experiments. This example models a photo-upload service; every product number below is a teaching assumption, not a claim about a named company.

Baseline assumptions

• 10 million daily active users.
• 2 original uploads per active user per day.
• 4 MiB mean encoded original object.
• Upload-start peak is 5 times the all-day average.
• 2 KiB metadata per upload, including indexed overhead for this first approximation.
• 365-day retention for a first-year logical-storage view.
• Derived media, replication/erasure coding, protocol overhead and retries are separate measured multipliers.

Use low/base/high ranges for uploads/user, payload distribution, peak factor, retention and derived-media ratio. A mean payload alone is insufficient for memory and timeout sizing; retain p50/p95/p99 and maximum limits.

Traffic

Daily upload starts:

10,000,000 users × 2 uploads/user/day = 20,000,000 uploads/day.

Average start rate:

20,000,000 / 86,400 ≈ 231.5 uploads/s.

Explicit peak scenario:

231.5 × 5 ≈ 1,158 uploads/s, rounded to about 1,160/s.

At 4 MiB mean payload, peak object ingress is:

1,158/s × 4 MiB ≈ 4,632 MiB/s ≈ 4.52 GiB/s.

Eight bits per byte gives about 38.9 Gbit/s of payload. TLS, HTTP, retransmission and aborted multipart overhead must be measured and added. Direct signed upload keeps that byte stream off the Upload API; the API is sized mainly for intent/completion request QPS and database work.

Storage

Logical original bytes per day:

20,000,000 × 4 MiB = 80,000,000 MiB ≈ 76.3 TiB/day.

First-year originals:

76.3 TiB/day × 365 / 1,024 ≈ 27.2 PiB.

Metadata:

20,000,000 × 2 KiB ≈ 38.1 GiB/day ≈ 13.6 TiB/year.

These are logical baselines. Add independent terms for derived variants, replication or erasure coding, object/version retention, incomplete multipart uploads, database indexes/WAL, compaction headroom, backups and migration space. Do not multiply by a storage factor until its semantics are clear.

Architecture consequences

The client first obtains an upload id plus an expiring signed URL restricted by owner, object key, size and content policy. Object storage validates checksum/size where supported. Object-created events are at-least-once, so media processing uses deterministic output keys and a stable source version. Metadata becomes ready only after required variants exist.

Unknown completion and duplicate events are normal recovery paths. Retries keep the same upload/event identity. A queue absorbs finite bursts; if arrival exceeds processing for long enough, oldest-event age grows. Measure worker service time and use Little's Law for average in-flight work, then load-test tails, memory and codecs.

Scenarios

▶Walkthrough: assumptions (not found)

Inputs are labelled and separated from arithmetic.

▶Walkthrough: upload-flow (not found)

Signed upload, at-least-once completion and idempotent media processing.

▶Walkthrough: traffic-math (not found)

Average and peak start rate plus byte/bit ingress conversion.

▶Walkthrough: storage-math (not found)

Original and metadata storage with binary units.

▶Walkthrough: sensitivity (not found)

One-variable-at-a-time review of bottlenecks and required measurements.

What must be measured next

• hourly/weekly start distribution and regional split;
• payload p50/p95/p99/max and abort/retry rate;
• intent DB transaction latency and index size;
• object-store request limits and multipart behavior for the chosen service;
• media CPU, memory, time and output-size ratio by format;
• queue delay, duplicate delivery and poison-item rate;
• restore, reprocess and deletion throughput;
• required SLO, failure domains and headroom during one-zone/worker-pool loss.

Primary sources

• NIST binary prefixes and byte definition: https://physics.nist.gov/cuu/Units/binary.html
• Little, A Proof for the Queuing Formula L = λW: https://pubsonline.informs.org/doi/10.1287/opre.9.3.383
• Google SRE, Addressing Cascading Failures and realistic capacity testing: https://sre.google/sre-book/addressing-cascading-failures/