Keep copies of the same data on several machines — for read scale and for surviving a machine failure — via leader and followers.
Replication keeps copies of the same data on several machines. It buys two things at once: fault tolerance (lose a machine, the data survives on the others) and read scaling (spread reads across the copies). The dominant pattern is leader-follower (also called primary-replica or master-slave).
One node is the leader (primary) and takes all writes — it's the single source of truth. Every change it applies is streamed to the followers (replicas), which keep matching read-only copies. Reads can be served by any follower, so you add read capacity simply by adding copies. Writes, however, always funnel through the one leader.
The key choice is *when the write is considered done*. Synchronous replication makes the leader wait for a follower to confirm it has the change before acknowledging the client — no data loss on leader failure, but every write pays the slowest follower's latency, and a stalled follower blocks writes. Asynchronous replication acknowledges the client immediately and streams to followers in the background — fast and available, but if the leader crashes before a change propagates, that write is lost. Many systems compromise with semi-synchronous: wait for *one* follower, stream to the rest async.
The lag problem above breaks a guarantee users expect: read-your-writes (read-after-write) consistency — after I write something, I should see it. Common fixes: route a user's reads to the leader for a short window after they write; track the write's log position and route the read to a follower that has caught up to it; or pin a user to one replica so at least they see a monotonic (never-going-backwards) view.
