Tutorials System Design Tutorial
Replication Topologies — Complete Guide
Replication Topologies — Complete Guide: free step-by-step lesson with examples, common mistakes, and interview tips — part of System Design Tutorial on Toolliyo Academy.
On this page
System Design Tutorial · Lesson 24 of 100
Replication Topologies
Basics → Scale → Interview
Basics · 1 — Building blocks · ~6 min · Module 3: Database Systems
What is this?
Replication copies data to secondaries: primary–replica, multi-primary, or quorum-based clusters — each with lag and failover behavior.
Why should you care?
ShopNest wants HA and read scale. Topology choice decides failover speed and conflict risk.
See it live — copy this example
Sketch the architecture on paper. These lessons focus on concepts and trade-offs.
Primary → Replica A (async)
→ Replica B (async)
Failover: promote A; apps use DNS/VIP
Sync replica: safer RPO, higher write latency
Multi-primary: write anywhere — conflict rules requiredRun Example »
This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.
What happened?
- Async replicas are common and can lose last writes on crash.
- Sync/quorum reduces loss but costs latency.
- Multi-primary needs conflict resolution.
Practice next
- Draw ShopNest primary + 2 async replicas.
- Send reports to replicas.
- Decide sync vs async for payments DB.
- Add a cross-region async DR replica.
- Measure replica lag and alert on it.
Remember
Replicas give HA and read scale. Async vs sync is an RPO/latency trade. Know your failover story.
ShopNest Postgres HA
Primary with async replicas; auto-failover VIP.
Outcome: Node loss triggers promote with known RPO.
Interview prep for this lesson
Practice these questions aloud after reading—each links to a full structured answer.
Sign in to ask a question or upvote helpful answers.
No questions yet — be the first to ask!
