Database Replication and Read Guarantees

Replication copies changes to another database location. It can provide a replacement when a machine fails and can move some reads away from the main writer. Those copies may be behind, so the application must decide which reads can tolerate old information.

Replication and sharding are different. Replication copies a dataset; sharding divides responsibility for different data. A system can use both.

With asynchronous replication, the writer can acknowledge before another copy receives the change. A failure can lose acknowledged changes that never reached the surviving copy. With a synchronous policy, acknowledgement waits for the configured replica condition, adding delay and dependence on those replicas.

Received, durably stored and applied for reads are different conditions. A policy that waits for durable receipt need not make a replica read immediately see the update. Check the specific database configuration rather than calling every replicated read “strongly consistent”.

The model starts with value 1 at both locations. Write increments the primary. Synchronise copies the latest value to the replica. Fail primary removes access to the writer without pretending a replacement has been safely promoted.

This is a local teaching state machine. It has no network timing, durability log or automatic leader election. Use the difference between the two values to reason about replica reads and possible failover loss.

A product description can sometimes tolerate a delayed copy. A user viewing their just-saved address may expect read-your-writes: their own successful change is visible. Route that read to the writer, wait for the needed replication position, or use a database feature that explicitly supplies the required guarantee.

Do not silently use a stale balance to approve a payment. Monitor replication lag and the read path, and state what happens when the freshness deadline cannot be met. Forcing all reads onto replicas is not a free performance improvement.

Promotion makes a replica responsible for future writes. First determine which data survived and stop the old writer from accepting conflicting writes. Fencing means preventing an old owner from continuing a protected operation, even if it later reconnects. A health check alone does not prove the old writer has stopped.

PostgreSQL offers streaming replication; MySQL offers replication options; managed database services package some failover operation. None removes the need to understand acknowledgement, lag and recovery. Read PostgreSQL’s standby and replication documentation.

Test lost responses, delayed replicas, promotion and return of the old node. Follow leader election for coordination and recovery for independent backups.

Eventual consistency means replicas are expected to converge under the system’s assumptions when updates stop and communication succeeds. It does not name a maximum stale time. A bounded-staleness contract requires an explicit bound and behaviour when it cannot be met.

A linearizable operation behaves as though it took effect at one instant between request and response, respecting completed operations in real-time order. “Strong consistency” is an ambiguous label without the actual guarantee and scope. Session guarantees such as read-your-writes can solve a narrower user need without promising linearizability for every read.

A single-writer design has one authority for an item’s updates. Multi-writer replication lets more than one location accept writes under a specific product contract, but concurrent changes can conflict. Timestamp-based last-writer-wins can discard one change; application merging needs a meaningful business rule. Do not assume two writable copies preserve both bookings or both balance updates.

Name the acknowledgement and read conditions. Treat lag, promotion and fencing as part of the data contract, and keep independent backups.