replication

If you keep your only photo album in one place and the house burns down, the photos are gone forever. So you make copies and store them in different places. Replication is that idea applied to data and services in a distributed system: keep several copies (replicas) of the same data on different machines, so that if one machine fails, the others still have the information and the system keeps running. It is the main tool for fault tolerance — surviving the loss of a node — and it can also speed things up by letting many machines serve reads at once.

The catch is keeping the copies in step when the data changes. There are two broad strategies. With synchronous replication, a write is not confirmed to the user until every (or a majority of) replica has stored it: copies stay tightly consistent, but the write is as slow as the slowest replica, and a write may stall if some replicas are unreachable. With asynchronous replication, the write is confirmed as soon as one replica has it and the others are updated shortly after: writes are fast and stay available, but for a brief window the replicas disagree, and if the primary crashes before it propagated the change, that change can be lost. A common middle path is a primary-backup scheme (one replica leads, others follow) versus a quorum scheme (a write must reach a majority, as in consensus).

Why it matters, and the honest tension: replication is how nearly every serious system survives hardware failure and serves a global audience. But it directly collides with the CAP theorem and with consensus. The more copies you keep and the more tightly you insist they agree, the more coordination (and delay) every update costs, and the more vulnerable you are to a partition that prevents reaching enough replicas. So replication is never free safety — it is a deliberate trade among durability, performance, and how much temporary disagreement (inconsistency) you are willing to tolerate.