Bandwidth-Driven Estimation

Foundations

So far, every estimate counted requests. Now, what if requests are rare but each one carries hundreds of megabytes, so the bytes, not the requests, set the design?

Multiply the request rate by the bytes per request to get bandwidth, and multiply daily bytes by 365 for yearly storage. Then assign each flow to the tier built for it: application servers handle small requests and metadata, object storage absorbs large uploads cheaply, and a content delivery network, CDN, serves popular bytes from caches near readers.

Take 100,000 uploads a day of 50 MB each. That is about one request per second, but 100,000 × 50 MB / 86,400 ≈ 58 MB/s of ingress and about 1.8 PB a year. If readers download ten times what is uploaded, egress is about 580 MB/s. The request rate fits one server; the bytes must bypass it.

• Estimation

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

  Open lesson

Case Scenario

To see how bytes can outweigh requests, consider a video platform like YouTube: users upload 2 million videos a day at about 200 MB each, and viewers stream 50 times more bytes than are uploaded. That is only 23 uploads a second, but about 4.6 GB/s in, 146 PB a year, and 231 GB/s out.

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.