We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Data Replication Distribution
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Data Replication Distribution
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
GitHub ran into a scaling wall around 2015. Their single MySQL primary with one replica could not keep up with the explosive growth of developers worldwide. Every git push, every issue comment, every PR review hit the database. Read traffic alone was overwhelming the single replica.
Their solution was straightforward: add more replicas. They went from one replica to three, then five, then eventually dozens. The primary still handled all writes, but reads were distributed across a fleet of replicas. Each replica was a full copy of the data, independently serving queries.
This is star topology: one central primary radiating out to multiple replicas, like the spokes of a wheel. It is the single most common topology in production today. If you are running MySQL or Postgres at any meaningful scale, you are probably using some form of star topology.
Shopify runs star topology on their MySQL shards, each shard having a primary with 3-5 replicas. Stripe runs Postgres in a similar configuration. Netflix uses Cassandra (which is internally mesh), but for their MySQL workloads they use star topology with ProxySQL managing read routing.
The structure is simple: one primary at the center, multiple replicas connected directly to it.
Read scaling is linear. Need 2x read capacity? Add another replica. Need 5x? Add four more. Each replica can independently serve the full read workload for any query against any table. With 4 replicas, you have roughly 5x the read of a standalone primary (primary + 4 replicas, each handling ~20% of reads).
Write scaling is not. Every write still goes through the single primary. Star topology does not help with write throughput. If you are write-bound, you need (partitioning across multiple primaries), not more replicas. This is the most common misconception about read replicas.
The primary's overhead grows with each replica. Each additional replica means another WAL sender process and another outbound stream. At 3-5 replicas, this is negligible: a few percent of CPU and a few MB/s of network. At 20+ replicas, the primary spends meaningful CPU and network on replication. Cascading replication (using replicas as sources for other replicas) mitigates this. GitHub uses a two-tier approach: the primary replicates to 3 "tier-1" replicas, and those tier-1 replicas cascade to additional "tier-2" replicas.
Replica roles can be specialized. Assign different replicas to different workloads:
This workload isolation prevents a heavy analytics query from causing latency spikes on user-facing reads.