What reached the second copy before success?

A second copy can help a database survive a machine failure. But “the write was replicated” is incomplete. Did the second machine receive bytes in memory, save them durably, or apply them so a query can read the new value?

Use one leader A and one follower B. The leader accepts a price change from 20 to 25 and sends its log record to B. A replica is another copy maintained from this update stream.

Follow the update through the follower

Assume B can recover a valid durable log and replay it correctly after a crash. A received record in volatile memory does not yet provide that recovery promise.

1. Received

   B has the record in memory. A power loss can still erase it.

2. Durable

   B has persisted the record under the storage assumptions. Recovery can replay it.

3. Applied

   B's queryable state now includes the price 25.

If A replies after its own durable write, before B persists anything, the response is faster but B might be missing an acknowledged update when A becomes unavailable. This is a possible asynchronous replication policy.

If A waits for both durable copies, the update can survive the loss of either machine’s storage, provided recovery uses the surviving copy. The price is that a slow or unreachable B can delay or prevent acknowledgment. This is a teaching policy, not a complete failover protocol.

Choose the next leader consistently

Suppose B has persisted the update but not applied it. A fails. B can recover and apply the record before serving reads. Returning 20 immediately would be inconsistent with a promise that every acknowledged update remains visible after failover.

Adding a third machine C does not remove this obligation. If C lacks the update, promoting C without reconciling the history can lose an acknowledged change even though B still has it. Safe replication needs an agreement about which history and which leader may continue. The next lesson introduces that agreement.

Replication also copies valid mistakes. A command deleting the wrong orders may reach every healthy replica. Recoverable history and backups remain necessary.

Predict the readable value

A waits until B reports the record durable. Immediately afterward, a query on B returns 20 because replay has not reached the record. Does “durable on B” alone make that read impossible?

Separate persistence from visibility

No. The record can be safe on storage while the readable state still lags. A stronger read promise requires waiting for the appropriate replay position or choosing a sufficiently advanced server. PostgreSQL exposes different synchronous-commit levels that make this distinction explicit.

Source: PostgreSQL 18’s standby replication and synchronous replication. Exact acknowledgment behavior depends on configuration; the example above names its own policy.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter

• Learning outcomes
• Copies do not decide when success is safe
• Leader and follower paths
• Synchronous and asynchronous replication
• Read routing and stale observations
• Quorum reasoning
• Leaderless writes and conflict resolution
• Repair and anti-entropy
• Promotion, fencing, and catch-up
• Write acknowledgment is a vector of progress
• Replication placement sets a latency floor
• Quorum intersection is necessary evidence, not a complete algorithm
• Concurrent writes need domain-aware interpretation
• Repair has its own consistency window
• Tombstones encode knowledge, not just absence
• Bootstrap requires a snapshot plus an ordered suffix
• Read scaling is conditional on freshness and workload
• Draw the sets before applying the quorum formula
• A failover decision should expose its contract
• Read replicas can improve write latency indirectly
• Case connection and design conclusion
• Sources and further reading