Data Replication

Data replication maintains multiple copies of data and propagates changes between them. Cloud storage and database services use replication to tolerate infrastructure failures, support recovery, and sometimes distribute read traffic. Replication can operate at the block, file, object, or database-record level. The key architectural question is not simply whether copies exist, but which failures those copies can survive and how applications access them afterward.

Replica placement determines the scope of protection. Copies on separate devices can protect against a disk failure, but copies within one Availability Zone do not provide protection against losing that entire zone. Replication across Availability Zones supports resilience to a zone failure. Cross-Region replication can support regional disaster recovery, geographic access, or regulatory requirements, but usually introduces greater network latency, transfer costs, and operational complexity.

Synchronous replication waits for the required replica acknowledgments before reporting a write as successful. Depending on the replication protocol and failure scenario, this can prevent the loss of acknowledged writes when a primary fails. The trade-off is additional write latency and possible write unavailability when required replicas cannot communicate. Synchronous replication does not necessarily mean that every copy has received the write; some systems require acknowledgment from a quorum.

Asynchronous replication acknowledges writes before all replicas receive them. It can reduce foreground write latency and is commonly used across Regions or for read replicas. However, a replica can lag behind the source. For example, a customer who updates an address and immediately reads from a lagging replica might see the old address. If the source fails before its latest writes are replicated, promoting that replica can lose those writes.

Recovery point objective, or RPO, describes the acceptable amount of data loss measured in time. Recovery time objective, or RTO, describes how quickly service must be restored. Replication lag influences achievable RPO, while failure detection, replica promotion, application reconnection, and routing influence RTO. A replicated copy alone does not guarantee automatic failover or uninterrupted service. Applications still need connection retries, appropriate timeouts, and a tested recovery process.

Durability and availability are different characteristics. Durability concerns retaining data without loss; availability concerns being able to access the service when needed. A highly durable storage system can temporarily be unavailable. Similarly, a readable replica might improve availability without containing the latest writes. Read replicas may increase read capacity, but they generally do not increase the write capacity of a single-writer database.

Replication is not a substitute for backup. Accidental updates, corrupted application writes, or malicious changes can propagate to replicas. Versioning, point-in-time recovery, retained backups, and immutable copies provide recovery options that live replicas alone do not. For example, replicate an order database across zones for infrastructure resilience while retaining backups to recover from an accidental table deletion.

Evaluate the replication behavior of each storage class and deployment option rather than assuming an entire service behaves uniformly. A block volume replicated within one zone remains tied to that zone's failure boundary, whereas a multi-zone storage service provides a different level of protection. Monitor lag and replication failures, verify permissions and encryption-key access at recovery locations, and test failover under realistic workloads. For architecture questions, match the required failure scope, data-loss tolerance, recovery time, consistency, and cost to the actual replication configuration.