Read/write ratio and the one-machine check

Once you have the numbers, run two checks. The first is the ratio of reads to writes, which tells you where to spend effort. The second asks whether a single machine could do the job, which is often the answer.

The read/write ratio

A read-heavy system can usually scale reads almost indefinitely with caches and replicas, since every replica can answer reads. Writes are harder. Every write must reach every replica. Once write volume exceeds what one primary can handle, you have to partition the data.

That asymmetry is why "how many writes per second at peak?" is often the most important number in an estimate.

Is this one machine?

Before you design a distributed system, check whether you need one. Many real products fit on one large database server with a replica for failover.

Take an internal B2B tool with 50,000 daily users, each making 200 API calls a day:

50,000 × 200 = 10M requests/day
10M ÷ 86,400 ≈ 115 requests/s average, about 350 at peak

Data: 20% of requests are writes of 1 KB
      2M × 1 KB = 2 GB/day ≈ 730 GB/year

That is one Postgres primary, one replica, a few stateless app servers behind a load balancer, and maybe a Redis instance. The working set fits in RAM on a machine with 1 TB of memory. The write rate is a few percent of what the database can sustain. Sharding this would add months of work and new failure modes for no gain.

Real systems go further than most people expect:

• In 2021, Let's Encrypt described running the database behind one of the internet's largest certificate authorities on a single MariaDB primary, with replicas, on a server with 64 CPU cores and 2 TB of RAM.
• Stack Overflow served a top-50 website for years from a handful of web servers and a pair of SQL Server clusters.
• Frank McSherry's paper "Scalability! But at what COST?" showed single-threaded laptop implementations beating distributed graph-processing clusters of up to 128 cores.

Common mistakes

• Designing for distribution by default. A distributed system adds failure modes. Earn them with numbers.
• Checking only request count. Also check the working set size and the write rate. A system can have modest traffic and still outgrow RAM.
• Ignoring the write path. Reads scale with replicas. Writes don't, so a high write rate is the real limit.

Check yourself

1. A system has 1,000 reads for every write. Where do you invest first? Caches and read replicas, because every replica can answer reads.

2. Peak writes are 40% of what one primary can sustain. What should you do? Stay on one primary for now, and write down the migration path. You still have headroom, and the growth rate tells you when it runs out.

Key takeaways

• The read:write ratio tells you where to invest. Reads scale with caches and replicas; writes need partitioning once they outgrow one primary.
• Peak write rate is often the single most important number.
• Many successful products run on one machine with a replica. Check before you distribute.
• Ask at what size one machine breaks, and how far away that is.

Further learning

The Let's Encrypt post above is a good example of a single-primary database at real scale. Next, try the arithmetic yourself in estimation practice.