Replication

You have a single database, and two worries creep in. First, it is handling every read and every write, and as reads pile up (remember, most systems are read-heavy) it becomes the bottleneck. Second, it is a single point of failure: if that one database dies, your whole app loses its data layer.

Replication addresses both by keeping copies of the database on more than one machine. The usual arrangement is one leader that accepts writes and several followers that hold copies. You send reads to the followers to spread the load, and if the leader dies, a follower can be promoted to take its place.

The catch, and there is always a catch, is that the copies are not updated instantly. This unit covers what replication buys you and the staleness price you pay for it.