Replication.

If your only copy of the data lives on one machine, that machine is a single point of failure: when it dies, so does everything. Replication keeps copies of the same data on several machines, so losing one is survivable, and readers can be served by a copy close to them.

Think of it as photocopying an important ledger and keeping copies in different offices. Everyone can read their nearest copy quickly, and if one office burns down, the others still hold the record. The hard part is keeping all the copies in step when the ledger changes.

Leader-follower, and the lag it brings

The most common setup has one leader take all the writes and stream its changes to follower copies, which serve reads. This spreads read load and gives you spare copies to promote if the leader fails. The catch is replication lag: a follower is always a little behind, so a reader might briefly see stale data — for example, you post a comment but a follower has not received it yet. That is eventual consistency in practice.

When one leader is not enough

A single leader is simple but limits write throughput and means a brief gap when it fails over. Multi-leader and leaderless designs let several copies accept writes — better for write scale and for users spread across the globe — but now two copies can be changed at once and disagree, so the system needs a way to detect and resolve conflicts. More availability and write capacity, more complexity to keep the copies sane.