Loading...
Loading...
Back-of-envelope estimation · plug in numbers, get answers
Presets are rough public-scale approximations for practice, not the companies real internals.
Sets your traffic baseline. Undercount this and every downstream number comes out too small.
Sets the average load your servers carry. Get this wrong and you underprovision for peak.
Splits reads from writes. Miss this and you undersize your database because writes always hit storage.
Covers traffic spikes above average. Skip this and your system falls over at peak hours.
Sets bandwidth and storage cost per request. Too low and both estimates come up short.
Share of requests carrying images or video. Ignore this and media bandwidth eats your budget.
Weight of each media item. Underestimate it and storage grows far faster than you planned.
How long storage piles up. Shave years off here and long-term disk cost catches you out.
Multiplies every stored byte. Set it to 1 and you lose data when a node fails.
Share of reads the cache absorbs. Overestimate it and your database takes more load than it can handle.
150 reads/s + 17 writes/s. This is your average load, size servers for the peak number above.
Text 83.3 KB/s + media 33.3 MB/s. Media usually dominates, this is the pipe you need to rent.
Text 720.0 MB + media 288.0 GB per day. This is how fast your disks fill each day.
288.7 GB/day × 1825 days × 3 replicas. This is the raw disk you pay for with replication accounted.
Cache absorbs 80% of reads, 17 writes/s always reach the DB. This is the query load your database must actually serve.
20% of one hour of reads (150 reads/s × 500 B each). Enough hot data to cover most reads without touching disk.
At peak 500 req/s ÷ ~10K req/s per server. Enough boxes to absorb peak with a little headroom.
10.0M users making 10.0K req/min. This ties traffic back to people so you can sanity check per-user load.