"Forty million daily users" sounds like a system that needs sharding, a queue in front of everything and a capacity meeting. Four minutes of arithmetic says otherwise.
The estimate
The course's order system has 40 million daily active users who place 0.15 orders each per day:
orders per day 6,000,000
write QPS (average) 69 peak 347
read QPS (average) 2,778 peak 13,889
storage 12,238 GiB over 365 days
write bandwidth 16.7 Mbps at peak
-> one primary, several replicas, a cache in front of reads
Sixty-nine writes a second, 347 at peak, is a load a single well-configured Postgres instance handles without effort. It comes from a system with forty million users, which is exactly the intuition the arithmetic corrects. Most systems that feel large are not, and the ones that are large are usually large in one dimension rather than all of them.
Five multiplications, in order
- Users × actions per user = actions per day.
- Actions per day ÷ 86,400 = average QPS.
- Average QPS × peak factor = peak QPS.
- Actions per day × bytes per action × retention = storage.
- Bytes per day × 8 ÷ 86,400 = average bandwidth, and the peak factor turns it into peak bandwidth.
Round aggressively. The answer you want is the exponent, not the digits, because the order of magnitude is what decides whether this design needs one database or forty.
Think Like an Engineer
Read the two lines separately. Writes stay small enough for one primary. Reads, at 40 for every write, are what the replicas and the cache are for. Estimate each dimension on its own before deciding which one the architecture has to scale.
Keep the numbers next to the diagram
Estimation is one of four questions the course asks before anything is drawn: which operations must work, how many and how skewed, what must be strongly consistent, and what failure costs. Write the answers beside the diagram, so that a changed answer shows which boxes it moves.
Suppose a stakeholder decides that order status must be strongly consistent after all. Reads move off the replicas onto the primary, so the 40:1 read-to-write ratio lands on one instance, unless you add a consistent-read mechanism, which costs latency. The cache in front of reads stops being usable for status unless it gains write-through invalidation, which is a consistency problem of its own. And 13,889 peak reads a second become a primary-database number rather than a fleet number. One answer changed, and three boxes did.
