Worked example for a Twitter-like app

Here is the whole chain on one realistic app. Every assumption is stated first, so you can change any one of them and see what moves.

Assumptions

• 200 million daily active users.
• Each user posts 0.5 tweets per day on average. Most post nothing, and a few post a lot.
• Each user loads their home timeline 20 times a day. Each load returns 20 tweets.
• A tweet row is about 300 bytes: IDs, up to 280 characters of text, timestamps and counters.
• 10% of tweets carry an image of about 500 KB after compression.

Traffic

Writes: 200M × 0.5 = 100M tweets/day
        100M ÷ 86,400 ≈ 1,160 writes/s average (about 1,000 with the 10^5 shortcut)
        × 3 peak       ≈ 3,500 writes/s peak

Reads:  200M × 20 = 4B timeline loads/day
        4B ÷ 86,400 ≈ 46,000 reads/s average
        × 3 peak    ≈ 140,000 reads/s peak

Ratio:  about 40:1 by request
        about 800:1 by tweet, since each load returns 20 tweets

Storage

Tweet text: 100M × 300 B = 30 GB/day
            × 365         ≈ 11 TB/year raw
            × 2 (indexes, overhead) ≈ 22 TB
            × 3 (replication)       ≈ 66 TB/year provisioned

Images:     100M × 10% = 10M images/day
            10M × 500 KB = 5 TB/day
            × 365        ≈ 1.8 PB/year in object storage

Bandwidth

Timeline JSON: 46,000 req/s × 20 tweets × 1 KB ≈ 0.9 GB/s ≈ 7.4 Gbps average

Images: each timeline load shows 2 thumbnails of 200 KB
        46,000 × 2 × 200 KB ≈ 18 GB/s ≈ 150 Gbps average
        18 GB/s × 86,400  ≈ 1.6 PB/day of egress
        1.6M GB × $0.05   ≈ $80,000 per day at list price (about $29M a year)

Servers

Timeline service: 140,000 peak RPS ÷ 5,000 RPS per box ≈ 28 boxes
                  ÷ 0.6 target utilization             ≈ 47 boxes, spread over 3 zones

Cache: about 3 cache operations per timeline read
       140,000 × 3 = 420,000 ops/s ÷ 100,000 per Redis node ≈ 5 nodes, plus replicas

What the numbers tell you

• Reads dominate 40 to 1, and each read touches 20 tweets. Precompute or cache timelines. This is the fan-out question in the news feed case study.
• 3,500 writes a second is within reach of one primary for throughput. But 66 TB a year is too much for one machine for long. Plan to shard by user or tweet ID.
• 1.8 PB a year of images belongs in object storage, never in the database.
• Image egress dominates the bill. At about 18 GB/s, images are roughly 20 times the bytes of the timeline JSON. A CDN and negotiated bandwidth pricing matter more than the database tier.
• 47 app servers and a few Redis nodes is a modest fleet. The hard parts are data layout and fan-out, not raw compute.

Common mistakes

• Sizing the image path like the text path. Measure bytes, not requests. Here the images are the bulk of the traffic.
• Leaving out the peak. The 3 times factor turns 46,000 reads a second into 140,000 to plan for.
• Rounding to four figures. Keep one significant figure. Nobody will mark you down for rounding.

Check yourself

1. Why is the read:write ratio 40:1 by request but 800:1 by tweet? Each timeline load returns 20 tweets, so each read request moves 20 times as many tweets.

2. What dominates egress in this design? The images: about 18 GB/s, against about 0.9 GB/s of timeline JSON.

Key takeaways

• Count bytes and requests separately. The heavy bytes can be on a different path than the heavy requests.
• The read:write ratio tells you to cache timelines.
• Images go to object storage behind a CDN, and the egress bill can exceed the cost of the database.
• Once the numbers exist, each one should point to a component.

Further learning

Next, see how to decide whether a system needs to be distributed at all in the read/write ratio and the one-machine check.