Section 3: Tiny Writes, Heavy Bytes - Scale Estimation & Workload Analysis

Executive Summary: This section derives every load number from one input, 20 million daily users, and finds four things. Writes are tiny (about 300 per second at peak), so one Postgres primary is enough. Search is the compute problem (10,500 QPS at peak). Photos are the byte problem (20 TB a day, about 72 Gbps of average CDN egress). And the search index is small, at 120 GB, so you shard it for throughput and locality, not for size.

The interviewer points at the board. "Tens of millions of users. Is this a big system?"

You write the inputs down first: 150M registered, 50M monthly, 20M daily active, US only. Then the two peak factors. Reads peak at 3x the average. Posting peaks at 5x, because people list things on Sunday evening. That's when Maya posts the Trek at 7:40 pm. "Big in some places, tiny in others. Let me show you which is which."

Step 1: Writes Are Tiny

New listings:   2,000,000/day / 86,400 s     ≈ 23/s avg   x5 → ~120/s peak
Updates:        3,000,000/day (edits, price drops, sold, renew, delete)
                                             ≈ 35/s avg   x5 → ~175/s peak
All listing writes                                          ≈ ~300/s peak

Active listings: 2M/day x 20 days avg live   = 40M
                 (30-day expiry, but most sell or are removed early)
Active set:      40M x 2 KB/row              = 80 GB
Per year:        2M x 365 = 730M x 2 KB      ≈ 1.5 TB/year

Three hundred writes a second is nothing: one Postgres primary handles it with large headroom, outbox row included. So the system of record is PostgreSQL: one primary, a synchronous standby, read replicas, partitioned by created month.

Interviewer: "Why not Cassandra? Marketplaces are huge."
You: "The bulk is photos, not rows. The row workload is read-heavy, and I want the listing and its outbox event in one transaction. I'd shard, or move to a managed KV store, if writes held above about 5K per second or hot data passed about 10 TB. We're far below both."

Quick check before moving on: