When bytes, not requests, set the design

Before you start

• Estimation

  That lesson converts product numbers into per-second rates and storage.

  Open lesson

Why it matters

Request counts hide the cost of large payloads. Two million uploads a day is only a few dozen requests per second, yet 200 MB per request changes the network and storage question, and viewers multiply those bytes fiftyfold. The design must place 4.6 GB/s of ingress, 146 PB of yearly storage, and 231 GB/s of egress without app servers proxying video bytes.

Users upload 2 million videos a day. An average video is 200 MB. Viewers stream 50 times more bytes than get uploaded.

Input

uploads_per_day = 2_000_000, mb_each = 200, egress_ratio = 50

Output

[4630, 146, 231]

For 2 million daily 200 MB uploads and 50× viewing, calculate 4.6 GB/s in, 146 PB/year stored, and 231 GB/s out; send uploader bytes to object storage and viewer bytes through a CDN.

Multiplying 2 million uploads by 200 MB and dividing by 86,400 gives about 4,630 MB/s of ingress, or roughly 37 Gbps. Multiplying the daily bytes by 365 gives about 146 PB added each year. These values describe data movement even though the request rate is only 23 uploads per second.

Uploaders receive signed destinations and send bytes to object storage; app servers keep metadata. At 50 times ingress, viewers demand about 231 GB/s, so cached copies are served through a CDN. This removes payload bandwidth from the app tier, but storage growth and CDN egress remain operating costs.