A company adds a database replica in a distant cloud region and configures it for synchronous replication so that no committed transaction can be lost. Immediately afterward, write transactions on the primary take noticeably longer to commit, although read queries are unaffected. What best explains the slowdown?

Synchronous replication guarantees zero data loss by making the primary wait for the replica to confirm that each transaction is durably received before the commit returns to the client. When the replica sits in a distant region, every commit now includes at least one network round trip across that distance, and physics sets a floor on that latency regardless of bandwidth. Reads are served locally and do not wait for replica acknowledgment, which is why only writes slow down. Encryption of replication traffic does consume some CPU, but modern processors handle transport encryption efficiently, and CPU cost would affect the server broadly rather than adding a consistent per-commit delay tied to distance. A replica applying changes works on its own copy of the data; it does not take locks on the primary's tables, so it cannot block transactions there. Replication ships log records or changed data, not the complete contents of every modified table on each commit; full resynchronization occurs only when a replica is first seeded or falls irrecoverably behind. Exam caveat: the usual design is synchronous replication between nearby zones for zero data loss and asynchronous replication to distant regions, accepting a small recovery point objective in exchange for commit latency. Operational check: measure the network round-trip time between regions, compare commit latency before and after the change, and consider asynchronous mode for the remote replica.