One estimate, start to finish

Size a photo sharing app for 50 million daily users, and say your assumptions first, because wrong and stated beats right and hidden. One user in ten uploads a photo daily, everyone views 50, photos average 300 KB compressed, and the record describing each one is a kilobyte.

Traffic first. Uploads are 5 million a day over roughly 100,000 seconds, so 50 writes a second and maybe 150 at peak. Views are 50 million times 50, so 2.5 billion a day, 25,000 reads a second on average and around 75,000 at peak.

The shape that falls out matters, because it governs everything after it. Reads outnumber writes 500 to one, so you are designing a read-optimised system.

Storage next. Five million photos at 300 KB is 1.5 terabytes a day, about 550 a year, and 1.6 petabytes a year once replicated three ways. The records describing them are 5 gigabytes a day, a rounding error beside that.

The consequence: photos and their records scale on completely different curves, so they belong in different systems. Object storage for one, a database for the other.

Bandwidth decides the design

Now bandwidth, where your design actually gets decided. 25,000 views a second times 300 KB is 7.5 gigabytes a second, so 60 gigabits on average and perhaps 180 at peak.

No single origin serves that. A content delivery network stops being an optimisation here and becomes load-bearing, and caching the hottest fifth of your photos at the edge cuts origin traffic to a fraction of it.

the shape of it

step 1 of 2

Each estimate feeds a decision, so the CDN, the object store, and the cache are chosen by arithmetic before any code exists.

the whole estimate, out loud, in four lines

Java

// State the assumption before the arithmetic, every time.
long users        = 10_000_000;        // daily actives, assumed
int  eventsEach   = 500;               // feed entries kept per user
int  bytesPerEvent = 200;              // id, type, timestamp, refs

long bytes = users * eventsEach * bytesPerEvent;   // 1e12, about 1 TB

// Now the sentence that matters: "a terabyte of memory, so this is
// a few thousand a month, and that is before replicas."

Worked example

Amara opens her system design interview by stating assumptions for a photo app, and the interviewer immediately changes one: make it 500 million DAU instead of 50. She doesn't restart, because everything is linear. Writes go from 50 to 500 per second, still trivial. Reads climb to 250,000 per second, storage to 15 TB a day, bandwidth to 600 Gbps average. The decisions shift exactly where the math says: metadata now genuinely needs sharding, since even a 90 percent cache hit rate leaves 25,000 reads per second, and she splits by user ID. The CDN conclusion doesn't move because it was already mandatory. Afterward the interviewer admits the 10x twist is deliberate: candidates who computed their numbers can rescale in seconds, while candidates reciting a memorized design have to start over.

A Worked Estimate, Start to Finish

One estimate, start to finish

Bandwidth decides the design

Worked example