Consistency and replication

all writes go to one node and the other copies exist only to be read from and to be promoted if it dies.

Leader-follower replication

you point the reporting queries at a copy of the database so they stop competing with checkout traffic.

Read replica

the commit does not return until at least one replica has confirmed it also has the write.

Synchronous replication

the primary acknowledges your write immediately and ships it to the replicas whenever it gets around to it.

Asynchronous replication

the replica is forty seconds behind the primary and the report you generated from it is missing this morning's orders.

Replication lag

you write to one node, read from another a moment later, get the old value, and it is correct a second after that.

Eventual consistency

every read is guaranteed to see the most recent committed write, so you never have to explain why the value went backwards.

Strong consistency

the user updates their profile, the page reloads from a replica, and their change is missing for two seconds.

Read-your-writes consistency

the page shows the new comment, you refresh, it disappears, you refresh again and it is back, because you hit three different replicas.

Monotonic reads

once one client has seen the new value, no other client is ever allowed to see the old one again.

Linearisability

the network between your two datacentres broke and you had to decide whether to refuse writes or accept divergence.

CAP theorem

you require three of the five nodes to acknowledge a write and two to answer a read, so the two sets always overlap.

Quorum

a group of nodes has to agree on one value and keep agreeing even when some of them are unreachable or lying about the order.

Consensus

you need exactly one instance to run the nightly job, so the instances have to agree among themselves who it is.

Leader election

the primary stopped answering and something promoted a replica, and now you find out how much of the last few seconds you lost.

Failover

the network partitioned, both sides decided they were the leader, and both accepted writes to the same data.

Split brain

the old leader wakes up from a long pause still believing it holds the lock, and the storage layer rejects its write because its number is stale.

Fencing token

two regions both accept writes to the same record and something now has to decide which version wins.

Multi-leader replication

two writes to the same key conflicted and the system kept the one with the later timestamp and silently threw the other away.

Last-write-wins

two replicas both took offline edits and merged them without a conflict, because the data type only supports operations that commute.

CRDT