# Replication strategies

> Choose how copies of the data stay in step, trading write latency and lost writes against stale reads and complexity.

Replication keeps more than one copy of the data, and the strategy decides when a write counts as done.

## Use it when

- One machine failing must not lose data or stop reads.
- Reads outnumber writes and one copy cannot serve them all.
- Users in other regions need a copy near them.

## How it works

There are four common shapes.

- **Leader and followers, asynchronous.** The leader confirms at once and followers catch up. Writes are fast, a follower can lag, and a leader that dies can lose the last writes.
- **Leader and followers, synchronous.** The leader waits for a follower. Nothing confirmed is lost, and every write pays the round trip.
- **Leaderless.** A client writes to several replicas and reads from several, and the [quorum](https://wiki.playquorum.dev/patterns/quorum-reads-and-writes.md) rule decides what a read sees.
- **Consensus.** A majority must agree on each write, so the group survives a minority failing. See [consensus and leader election](https://wiki.playquorum.dev/patterns/consensus-and-leader-election.md).

## What it costs

Each shape gives up something. Asynchronous copies serve stale reads and lose writes in a crash, synchronous ones slow every write and stop writes if the replica goes down, and leaderless stores need quorum math. Accepting writes on more than one node, as multi-leader and leaderless setups do, adds write conflicts that someone must resolve. Replication also does not protect against a bad delete, because the delete replicates too, so keep backups.

## In Quorum



A [Read Replica](https://wiki.playquorum.dev/components/replica.md) is asynchronous by default, so it lags and some reads come back stale. Turning on **Synchronous** makes every write wait for it, which removes stale reads and adds a round trip, and if the replica goes down, writes time out until it returns. It needs [Synchronous replication](https://wiki.playquorum.dev/research/sync-replication.md) after [Read replicas](https://wiki.playquorum.dev/research/replication.md).

The [Wide-column Store](https://wiki.playquorum.dev/components/wide.md) is leaderless, and [Distributed SQL](https://wiki.playquorum.dev/components/dsql.md) is consensus. The [Replication lag](https://wiki.playquorum.dev/incidents/repl-lag.md) incident shows the asynchronous cost. The glossary defines [synchronous replication](https://wiki.playquorum.dev/glossary/synchronous-replication.md) and [replication lag](https://wiki.playquorum.dev/glossary/replication-lag.md).

Source: https://wiki.playquorum.dev/patterns/replication-strategies