Synchronous replication coordinates writes across multiple copies of data before reporting success. A primary database or storage system accepts a change, sends the required data or transaction log records to replicas, and waits for the configured acknowledgment condition. That condition might require one designated standby or a quorum of storage replicas. The exact guarantee depends on what each acknowledgment means: receiving a record in memory, persisting it to durable storage, and applying it so that queries can see it are different milestones.
The main business-continuity benefit is protection of acknowledged writes. If the primary fails after a transaction succeeds, a surviving replica that participated in the required durable acknowledgment can preserve that transaction. This supports a recovery point objective, or RPO, of zero within the defined failure scope. It does not imply a recovery time objective, or RTO, of zero. Failure detection, selection of a recovery target, database recovery, endpoint changes, and application reconnection can still interrupt service.
In cloud architectures, synchronous replication commonly operates across Availability Zones within one Region. This separates copies into different failure domains while keeping network latency relatively low. For example, an order-processing database can synchronously replicate committed transactions to a standby in another zone. If the primary zone becomes unavailable, the service can promote the standby without losing successfully acknowledged orders, assuming the failure is within the deployment's documented guarantees.
The cost is additional work and communication on the write path. Commit latency includes the required replica acknowledgments, so network round-trip time and replica storage performance affect application response time. Synchronous replication across geographically distant Regions is possible in some systems, but propagation delay can make it unsuitable for latency-sensitive workloads. A common design therefore combines synchronous replication within a Region with asynchronous replication to a disaster-recovery Region, accepting a different RPO for regional disasters.
Network partitions expose an important availability trade-off. If the required acknowledgments cannot be obtained, a system might block writes, reject them, or reconfigure its replication membership according to its documented safety rules. A configuration that falls back to asynchronous operation can continue accepting writes but changes the data-loss guarantee. Quorum rules, leadership election, and fencing must prevent isolated writers from independently accepting conflicting updates.
Synchronous replication does not mean every replica is immediately available for current reads. A replica may have durably received transaction logs without applying them yet, and read consistency depends on the database's read-routing and isolation behavior. It also does not mean all copies must acknowledge every write; quorum-based systems can remain safe while some replicas are unavailable. Conversely, a replica called a read replica or a deployment called Multi-AZ should not be assumed to use synchronous replication without checking its specific architecture.
Replication is not a backup because accidental deletion, corruption, or unwanted application updates can propagate to the replicas. Retain independent backups and point-in-time recovery capabilities. When improving an existing solution or designing a new one, define RPO and RTO separately for instance, zone, and Region failures. Then validate acknowledgment durability, failover eligibility, partition behavior, commit latency, and application retry handling through failure tests. A timeout can leave a client uncertain whether a transaction committed, so idempotent requests remain important even when replication protects the data.
Amazon RDS
Amazon Aurora