data-stateestablished · high operational burden

Database Replication

Also known as: replication, streaming-replication, logical-replication, multi-master

Intent

Copy data across database nodes for availability, read scaling, and disaster recovery, understanding sync vs async trade-offs.

Problem

Single database = single point of failure. Read load exceeds write capacity. Need geo-distribution.

Forces

•RPO/RTO: sync (RPO=0) vs async (RPO>0)
•Consistency: strong (sync) vs eventual (async)
•Latency: sync adds commit latency; async doesn't
•Conflict resolution: multi-master needs conflict handling

Solution

✓ When to Use

•Any production database needing HA
•Read scaling (async replicas)
•Geo-distribution (async cross-region)
•RPO=0 requirements (sync)

✗ When Not to Use

•Dev/test (single node fine)
•Team not ready for failover drills
•Multi-master without conflict strategy

Pros

+HA: automatic failover, minimal downtime
+Read scaling: offload analytics, reporting
+DR: cross-region replica
+Zero-downtime upgrades: promote replica

Cons

−Replica lag: stale reads, failover data loss
−Split-brain: two primaries (mitigate: fencing, quorum)
−Schema changes: replication breaks if not careful
−Monitoring: lag, gaps, replication health

Cost Profile

Infrastructure

Medium — replica nodes, network

Operational

High — failover drills, lag monitoring, schema coordination

Cognitive

Medium — sync vs async, topology choice

Failure Modes

Replica lag spikes: stale reads, failover loses data
Split-brain: network partition → two primaries
Replication gap: WAL files removed before replica catches up
Schema change breaks replication: DDL not replicated
Failover script bug: promotes wrong node, data loss

Real-World Examples

Alternatives

read-replica
cdc
partitioning
disaster-recovery
multi-region

Related Patterns

read-replica
disaster-recovery
cdc
multi-region
synchronous-replication
failover

Competency Domains

data statereliability opsdistribution communicationeconomics evolutionscaling