A replica holds another copy of state. Its usefulness depends on how it receives changes, which acknowledgment the writer waits for, and how a new owner is selected after a failure. Having three servers does not, by itself, define which data survives or how quickly the service recovers.
Durability describes which acknowledged effects are preserved under a failure model. Availability describes whether an operation can be served. Replication can help both, but it does not make them equivalent or replace a restorable backup.
What acknowledging a write means
The contract begins with the acknowledgment. A database may acknowledge after recording a change locally and sending it asynchronously to another instance. If the primary disappears before that replica receives it, promoting the replica can lose a write the client already considered complete.
PostgreSQL supports synchronous replication configured to wait for acknowledgments from designated standbys. The waiting level distinguishes receipt, persistence, or application, depending on configuration. This choice adds latency and can block writes when required participants do not respond. It does not mean that every combination of losses is tolerated.
The consistency contract also defines where reads come from. A durable write on the primary may not yet be visible on a read replica.
Copies and observable progress
The diagram represents asynchronous replication. The client acknowledgment does not assert that every log consumer has reached the same position.
--- config: look: handDrawn --- flowchart TD client["Client"] --> writer["Authoritative primary"] writer --> log["Durable local log"] log --> ack["Client acknowledgment<br/>Under the contract"] log -->|"Asynchronous replication"| replica["Replica<br/>Measured progress"] replica --> read["Read with a<br/>freshness contract"] log --> backup["Backup and log archive<br/>Independent retention"]
Both the distance between positions and its age are observed. A small number of pending bytes does not guarantee a short time lag if the destination has stopped applying changes. Metrics should distinguish transport, persistence, and application when the engine exposes them.
Failover and write authority
Promoting a replica means choosing which history is preserved and who can write. The former primary may remain alive after a network partition. If both accept independent changes to the same identity, resolving the conflict later may violate inventory or payment invariants.
The architecture needs an election and exclusion mechanism compatible with the engine: coordinated membership, fencing, or effective removal of the old writer. Changing DNS does not stop existing connections or prove that the previous owner has been fenced off. Clients, pools, and background processes must recognize the new authority.
A timeout during the transition does not prove that a write aborted. Recovery uses the same operation identity and queries the durable result, as explained in Idempotency and Uncertain Outcomes.
Reads and additional replicas
A replica can offload queries, but it does not automatically divide the load of an authoritative write. Heavy queries can also delay log application or increase costs, depending on the engine and configuration.
For reads after a write, the application can use the writer or a replica that has reached a known position, if the system offers that check. Waiting has a deadline and a fallback policy. The application should not advertise strong freshness just because all nodes are healthy.
In Sharding, each shard needs its own replication, failover, and backup policy. Distributing data across shards and maintaining copies are separate decisions; both must preserve the owner of each partition.
Zone, region, and backup
| Mechanism | Failure it may address | What remains to be verified |
|---|---|---|
| Replicas across zones in one region | Loss of an instance or zone, depending on the design. | Promotable compute, exclusion of the former writer, and client recovery. |
| Copy in another region | Regional disaster or geographic continuity. | Lag, possible loss, regional dependencies, and the failover procedure. |
| Backup with history | Logical deletion, corruption, or recovery to an earlier point. | Retention, permissions, integrity, and rehearsed restoration. |
Aurora distinguishes storage redundancy across zones in one region from Global Database replication across regions. A planned switchover can wait for synchronization; an unplanned failover may lose changes that have not yet replicated. The concrete guarantees belong to that product and configuration.
Replicating an incorrect deletion also copies the mistake. An independent backup is not useful if its keys, permissions, or procedure exist only in the lost environment.
RTO and RPO with assumptions
RTO is the target time to recover service; RPO is the tolerated data loss, commonly expressed as a time distance. These are objectives to test in drills, rather than guaranteed outcomes from selecting a Multi-AZ option.
As a hypothetical example, a team might request a fifteen-minute RTO and a thirty-second RPO for a catalog. The drill measures detection, decision, promotion, reconnection, and functional verification. A replica two minutes behind violates that RPO even if it responds quickly after promotion.
A confirmed sale may require a stricter contract than the catalog. Objects, queues, secrets accessible through authorized mechanisms, and dependent services also matter. Recovering only the database does not demonstrate recovery of the complete flow.
Verify before the incident
Drills include stopping a primary, isolating it without shutting it down, delaying a replica, and restoring a backup in a separate environment. They check that two valid writers never appear, that uncertain attempts can be resolved, and that reads satisfy the advertised contract.
Version, position, observed loss, duration of each phase, and reconciled differences are recorded. Observability of invariants checks outcomes as well as process health. An incomplete exercise is described as such; recovery depends on the boundaries actually tested.
References: PostgreSQL synchronous replication and Aurora Global Database regional recovery.