3.5M/s
image requests every second
Assume 1.5 billion daily users each see 200 images. A CDN answers about 90%. What’s left, after an origin cache, is 175k disk reads a second.
Where do the bytes go?
Bad: Through API servers
14 GB/s at peak; slow 3G holds workers; a drop restarts from zero.
Good: Straight to storage
Signed URL, resumable 256 KB chunks, begun before you tap Share.
Your 2019 Leh trip, unseen for months. How many disk reads?
One file per photo reads the directory, the inode, then the data. Pack them into 100 GB volumes with a RAM index: one read.
Posts live on thousands of shards. Find any post’s shard without asking a directory.
The trick
Put the shard in the ID: 41 bits of time, 13 of shard, 10 of sequence, made inside Postgres.
A star with 300 million followers posts during the IPL final.
Pushing is 300 million inserts, five minutes at a million a second, with the queue jammed. Above about 1M followers, readers pull instead.
Sixty follows have live Stories. Which rings stay coloured?
Story IDs sort by time, so keep one pointer per viewer and author, the last ID you watched. A newer live Story keeps the ring coloured.
15,000 likes a second on one row? Batch the count.
- Keep every like row exact, keyed post + user
- Write the summed count once a second
- Show “1.2M likes”; nobody sees the last digit
Remember
Split bytes from records: bytes go straight to storage, out through a CDN, one seek when cold. Records shard by author; feeds push except for celebrities; hot counts batch.