Topic 8.1
Replication
In one line
Copies of the same data on multiple nodes: primary handles writes, replicas serve reads and take over on failure.
Think of it like this
A popular library making photocopies of a book for its branches. The main branch (primary) has the master copy and handles all edits; the other branches (replicas) just hand out photocopies to readers, which is much faster than everyone crowding into one building.
Key ideas
- 01
Primary (leader) accepts writes and streams changes to replicas (followers) — read replicas scale reads.
- 02
Why replicate: read scaling, availability (failover), disaster recovery, latency (regional replicas).
- 03
Synchronous vs async replication: sync = durable but slow (write waits); async = fast but a crash can lose unfsynced writes.
- 04
Replication lag: async replicas are slightly behind — 'read from my own writes' on the primary fixes the worst case.
- 05
Failover: when the primary dies, promote a replica; health checks + consensus (or a coordination service) choose it.
- 06
Multi-primary and leaderless (Dynamo-style) replication exist — mention them, then say why single-primary is the default.
Java / Spring map
- →
Spring Data + Postgres: configure read-only DataSource routing (AbstractRoutingDataSource) for replica reads.
Code & diagrams
Writes go one way, reads scale out sideways — and the gap between them is the replication lag.
Explain without notes
A user posts a comment and refreshing shows nothing. Walk the replication-lag story and the 'read-your-writes' fix.
Practice
Model read replica routing + failover + the window where writes are lost, with a diagram.
Trade-offs
- ↔
Async = fast reads, bounded staleness; sync = zero loss, slower commits. State your freshness budget.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can explain primary/replica, lag, failover, and read-your-writes in one coherent flow.