Replication

One copy of your data means one machine whose failure loses everything, and one machine that has to serve every read. Replication fixes both. Extra copies survive a failure, and they can answer reads.

All the difficulty is in writes. As soon as two copies can be written to on their own, they can disagree. So you have to decide in advance who wins.

Leader and follower is the default, and the one to reach for. All writes go to one leader. Followers copy from it and serve reads. It is simple, write conflicts cannot happen by design, and it is what a normal relational database does out of the box. The costs: the leader caps your write rate, and when it dies something has to notice and promote a follower. Writes fail while that happens.

Failover has one nasty failure worth naming: split brain. The old leader was not dead, only unreachable. Now there are two leaders taking writes, and they drift apart. The defence is a majority rule, where only a node that can talk to more than half the cluster may be leader. Add fencing, so the storage layer refuses the old leader when it comes back. Also, whatever the old leader accepted but had not yet copied is gone. Someone has to decide whether that loss is acceptable.

The main knob is synchronous versus asynchronous replication. Synchronous means the write is not confirmed until a follower has it. No data is lost on failover, but writes now wait for the slowest follower, and if that follower is down, writes stop. Asynchronous means fast writes and a window where data can be lost. The usual middle ground is semi-synchronous: one follower synchronous, the rest asynchronous. You get safety without depending on all of them.

Multi-leader means several leaders accept writes, usually one per region. Local writes are fast everywhere. But now the same row can be edited in two places at once, and you have to resolve that. Options: last-write-wins, which is simple but throws away someone's work without an error, and depends on clocks you cannot trust. Or a merge rule written by your application. Or a data type designed to merge cleanly. Use multi-leader when local write speed matters and conflicts are rare: collaborative editing, offline-first apps.

Leaderless means the client writes to several nodes and reads from several. With N copies, if writes go to W nodes and reads to R nodes, and W + R > N, then any read touches at least one node that saw the latest write. It is tunable and survives failures well, and it pushes conflict handling onto you. Repairs also happen lazily, so a node can serve old data until it is fixed.