replication-patterns

name	replication-patterns
description	Use when designing how a database keeps multiple copies of its data in agreement across nodes for availability, read scaling, and disaster recovery: the three foundational topologies (single-leader / primary-replica, multi-leader / multi-primary, leaderless / quorum), synchronous vs asynchronous replication and the replication-lag trade-off, log shipping vs statement replication vs trigger-based replication, the read-after-write consistency problem and its mitigations (sticky session, read-from-leader, monotonic reads), the failover model and split-brain risk, and the relationship to the CAP/PACELC choices the topology realizes. Do NOT use for horizontal partitioning across nodes (use sharding-strategy), the CAP theoretical frame itself (use cap-theorem-tradeoffs), single-node transactional guarantees (use acid-fundamentals), or query tuning (use query-optimization).
license	MIT
allowed-tools	Read Grep
metadata	{"metadata":"{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"engineering\",\"domain\":\"engineering/data\",\"scope\":\"reference\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-16\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-16\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"comprehension_state\":\"present\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"replication\\\\\\\",\\\\\\\"primary replica\\\\\\\",\\\\\\\"multi-leader\\\\\\\",\\\\\\\"leaderless\\\\\\\",\\\\\\\"quorum\\\\\\\",\\\\\\\"synchronous replication\\\\\\\",\\\\\\\"asynchronous replication\\\\\\\",\\\\\\\"replication lag\\\\\\\",\\\\\\\"read-after-write\\\\\\\",\\\\\\\"failover\\\\\\\",\\\\\\\"split brain\\\\\\\",\\\\\\\"log shipping\\\\\\\",\\\\\\\"WAL streaming\\\\\\\"]\",\"triggers\":\"[\\\\\\\"single-leader vs multi-leader\\\\\\\",\\\\\\\"synchronous vs async replication\\\\\\\",\\\\\\\"what happens on failover\\\\\\\",\\\\\\\"split brain\\\\\\\",\\\\\\\"read-after-write consistency\\\\\\\"]\",\"examples\":\"[\\\\\\\"design replication topology for a service with one region writing and three regions reading\\\\\\\",\\\\\\\"decide between synchronous and asynchronous replication given a target RPO\\\\\\\",\\\\\\\"diagnose stale reads after a write — likely replication lag without read-after-write handling\\\\\\\",\\\\\\\"explain the split-brain risk in multi-leader replication\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"horizontally partition data across nodes (use sharding-strategy)\\\\\\\",\\\\\\\"reason about the CAP theorem abstractly (use cap-theorem-tradeoffs)\\\\\\\",\\\\\\\"explain ACID properties (use acid-fundamentals)\\\\\\\"]\",\"relations\":\"{\\\\\\\"related\\\\\\\":[\\\\\\\"cap-theorem-tradeoffs\\\\\\\",\\\\\\\"acid-fundamentals\\\\\\\",\\\\\\\"sharding-strategy\\\\\\\",\\\\\\\"transaction-isolation\\\\\\\"],\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"cap-theorem-tradeoffs\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"cap-theorem-tradeoffs owns the theoretical frame for the consistency-availability trade-off; this skill owns the operational topologies and protocols that realize a chosen position on that trade-off. The two compose: CAP names the choice; replication-patterns is one of the realizations.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"sharding-strategy\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"sharding-strategy owns horizontal partitioning of data across nodes (different nodes hold different data); this skill owns replication of the same data across nodes (multiple nodes hold the same data). The two often combine in production systems but answer different questions.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"acid-fundamentals\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"acid-fundamentals owns the single-system transactional model; this skill owns the multi-node replication patterns that distributed systems use to scale, replicate, and survive failure. Replication often relaxes some ACID properties (most notably durability and isolation in async modes).\\\\\\\"}],\\\\\\\"verify_with\\\\\\\":[\\\\\\\"cap-theorem-tradeoffs\\\\\\\",\\\\\\\"sharding-strategy\\\\\\\"]}\",\"mental_model\":\"|\",\"purpose\":\"|\",\"boundary\":\"|\",\"analogy\":\"Replication is to a database what mirror copies of a master photograph are to a museum's record — single-leader async is the photographer keeping the negative and printing copies as requested; single-leader sync is the conservator requiring two darkroom signatures before any print leaves the building; multi-leader is multiple authorized photographers in different cities each accepting submissions and reconciling at intervals; leaderless quorum is asking three of five archivists to vote on whether this print matches the master, accepting their verdict. Failover is replacing the negative-keeper when they retire; split brain is what happens when the agency forgets to revoke the old keeper's keys.\",\"misconception\":\"|\",\"concept\":\"{\\\\\\\"definition\\\\\\\":\\\\\\\"Replication is the discipline of keeping multiple copies of the same data on multiple nodes so that the system can serve reads from any copy, survive the failure of any node, or both. The three foundational topologies are single-leader (primary-replica; one node accepts writes, others receive a stream of changes), multi-leader (multi-primary; multiple nodes accept writes and reconcile), and leaderless (quorum; clients write to a quorum of nodes directly). Each topology has its own consistency, availability, con…","skill_graph_source_repo":"https://github.com/jacob-balslev/skill-graph","skill_graph_protocol":"Skill Metadata Protocol v4","skill_graph_project":"Skill Graph","skill_graph_canonical_skill":"skills/replication-patterns/SKILL.md"}

Replication Patterns

Coverage

The catalog of replication topologies and the operational discipline that makes them work in production. Covers the three foundational topologies (single-leader / primary-replica, multi-leader / multi-primary, leaderless / quorum), the synchrony spectrum (sync, semi-sync, async, quorum-sync), the mechanism choices (statement-based, row-based, trigger-based, logical, physical), the read-after-write consistency problem and its mitigations (sticky session, read-from-leader, monotonic reads, version tokens), the failover model and quorum-based split-brain prevention, the conflict-resolution choices in multi-leader and leaderless systems (LWW, CRDTs, vector clocks, application merge), and the relationship to the CAP/PACELC choices the topology realizes.

Philosophy

Replication is the discipline that gives a database fault tolerance, read scaling, and disaster recovery — at the cost of consistency-handling, conflict resolution, and operational complexity.

The default starting point is single-leader with asynchronous replication: simple, well-understood, sufficient for most read-mostly workloads. The departures from this default — multi-leader, leaderless, synchronous, geographic — each address a specific requirement (multi-region writes, strong consistency under partition, RPO=0) and add proportional complexity.

The most common production failures are not in the replication topology itself but in the application's handling of its consequences: stale reads producing user-visible bugs, split brain producing silent data divergence, failover producing unrehearsed surprises. The discipline is treating replication as an architecture the application is co-designed with, not a database feature that handles itself.

Topology Selection

Topology	Best for	Trade-offs
Single-leader, async	Read-heavy workloads with tolerance for stale reads	Replication lag; possible data loss on leader failure
Single-leader, sync	Workloads requiring RPO=0	Write latency; replica failure can block writes
Multi-leader	Multi-region writes; active-active disaster recovery	Conflict resolution complexity
Leaderless (quorum)	High availability with tunable consistency	Read latency = slowest of R; quorum-sizing decisions
Synchronous via Raft/Paxos (Spanner, CockroachDB)	Strong consistency at scale	High write latency for distant replicas

The starting point for most workloads is single-leader async; depart from this default only when the workload requires it.