Back-of-Envelope Estimation: The Art of Smart Calculation

The Number That Changed a Design: 12,000 Writes/Sec

A candidate designing a social media feed estimated 100M DAU with 10 posts per day. Quick math: 100M * 10 / 86,400 = ~12,000 writes per second. That single number changed everything. At 12,000 writes/sec, a single PostgreSQL instance (which handles ~5,000 writes/sec) is not enough. They needed sharding. But 12,000 also is not so high that they needed Cassandra. The estimation drove the architecture. Without it, they would have either over-engineered (Cassandra for 100 writes/sec) or under-engineered (single Postgres for 100,000 writes/sec).

The Engineer's Cheat Sheet

Numbers Every Engineer Should Know:

Latency:
  L1 cache reference:           1 ns
  L2 cache reference:           4 ns
  RAM reference:               100 ns
  SSD random read:             100 us  (microseconds)
  HDD random read:           10,000 us (10 ms)
  Network round-trip (same DC): 500 us
  SF to NYC:                    40 ms
  SF to London:                 80 ms
  SF to Sydney:                150 ms

Throughput:
  PostgreSQL writes:        5,000-10,000/sec
  Redis operations:       100,000-500,000/sec
  Kafka (per broker):      100,000 msgs/sec
  Cassandra (per node):     10,000-50,000 writes/sec

Storage:
  1 char (UTF-8):              1-4 bytes
  1 tweet (280 chars):         ~1 KB with metadata
  1 photo (compressed):        200 KB - 2 MB
  1 min HD video:              ~100 MB
  1 billion rows * 1 KB:       1 TB

Scale shortcuts:
  Seconds in a day:        ~100,000 (86,400)
  Seconds in a year:       ~30,000,000
  1 million / 100K sec/day = ~10/sec average

Estimation Template

Step-by-Step Estimation (Social Media Example):

  1. Users:      100M DAU
  2. Actions:    10 posts/day, 100 reads/day per user

  3. Writes/sec: 100M * 10 / 100K = 10,000 writes/sec
  4. Reads/sec:  100M * 100 / 100K = 100,000 reads/sec
  5. Read:Write: 100,000 / 10,000 = 10:1 ratio

  6. Storage/day:
     10,000 writes/sec * 100K sec/day * 1 KB = 1 GB/day
     With media: 1 GB * 100 (avg 100KB attachment) = 100 GB/day
     Per year: 100 GB * 365 = ~36 TB/year

  7. Bandwidth:
     100,000 reads/sec * 1 KB = 100 MB/sec egress
     With media: ~10 GB/sec (CDN absorbs 95%)

  Architectural decisions from these numbers:
  - 10K writes/sec: need 2-3 DB shards or write-optimized DB
  - 100K reads/sec: Redis caching layer required
  - 36 TB/year: S3 for media, DB for metadata only
  - 10 GB/sec: CDN mandatory for media serving

Interview Tip

The goal of estimation is not precision - it's identifying the order of magnitude. Round aggressively (86,400 to 100,000, 1M users to 10^6). The four numbers that matter: writes/sec, reads/sec, storage/day, and bandwidth. Each one maps directly to an architectural decision. Show the interviewer how your numbers drive your choices: 'At 10K writes/sec, I need sharding' is much more convincing than 'I think we should use sharding.'