replication-patterns

Database replication prevents split brain by applying quorum-based promotion and fencing during failover. You maintain consistency by selecting an appropriate topology like primary-replica or leaderless, combined with synchronous or asynchronous replication tuned to your workload.

Avoid stale reads after a write by applying read-after-write mitigations such as sticky sessions, reading from the leader, monotonic reads, or version tokens. Choose the strategy that best balances latency against your workload's consistency requirements.

Choose between synchronous and asynchronous replication by evaluating your latency, recovery point objective (RPO), and failure behavior needs. Synchronous offers stronger consistency, while asynchronous reduces latency but risks data loss during failover.

Use a leaderless quorum topology when you need high write availability and multi-primary conflict tolerance across regions. Choose primary-replica setups when your workload is read-heavy and prefers simpler consistency models with a single write leader.

Multi-primary replication improves write availability but requires explicit conflict resolution and fencing to prevent silent data divergence. You must design operational practices that monitor replication lag and enforce quorum to keep multi-node data copies consistent.

Read-after-write consistency fails with asynchronous replication because replicas lag behind the primary, causing stale reads. Fix this by routing reads to the leader, using version tokens, or implementing sticky sessions to ensure clients read their own writes.