{"post":{"slug":"synchronous-replication-2026","title":"Synchronous Replication: Paying Latency for Durability","excerpt":"Waiting for a replica to confirm every commit removes the data-loss window on failover. It also puts a network round trip in the path of every single write.","category":"code","date":"January 19, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">A</span>synchronous replication acknowledges a commit as soon as the primary has it durably. The replica receives the change shortly after. If the primary fails in that window, those writes are lost — the replica is promoted without them.\n\nSynchronous replication closes that window by waiting for a replica to confirm before acknowledging the commit. Nothing is acknowledged that is not on at least two machines.\n\n## What changed in 2026\n\n- **Quorum-based configuration became standard.** Requiring a majority of several replicas rather than one specific replica removed the single-point dependency.\n- **Managed platforms offered it as a toggle.** Selecting the durability level became a configuration choice rather than an infrastructure project.\n- **Cross-region cost stayed prohibitive for most.** The latency of synchronous cross-region commits kept it a specialist choice.\n- **Mixed configurations spread.** Synchronous locally, asynchronous to a distant region, became a common shape.\n\n## What you gain and pay\n\n| | Asynchronous | Synchronous |\n| --- | --- | --- |\n| Commit latency | Primary only | Primary plus replica round trip |\n| Data loss on failover | Recent writes | None acknowledged |\n| Replica failure impact | None on writes | Can block writes |\n| Cross-region viability | Good | Expensive |\n| Throughput | Higher | Lower |\n\nThe gain is precise: **no acknowledged write is lost on failover.** If your system told a user something succeeded, it survives the primary failing.\n\nThe cost is equally precise: a network round trip on every commit. On a local network that is small; across regions it is tens of milliseconds, on every write, forever.\n\n## The availability trap\n\nNaive synchronous replication creates a dependency people do not anticipate: if the replica is down or slow, commits block.\n\nYou configured replication for durability and got a system where a replica failure causes a write outage — a worse availability posture than before.\n\nThe fix is quorum-based configuration: require confirmation from *any* one of several replicas, or from a majority, rather than from one named replica. Then a single replica failing does not block anything, because another can acknowledge.\n\nThat requires at least three replicas to be meaningful. With one synchronous replica, its failure is your outage.\n\nSome systems also degrade automatically, falling back to asynchronous when no replica can confirm. That preserves availability and silently gives up the guarantee — which may be right, and should be a deliberate choice rather than a surprise discovered after an incident.\n\n## Where it belongs\n\nSynchronous replication is a durability decision, and durability requirements vary by data.\n\n**Worth it:** financial transactions, order placement, anything where losing an acknowledged write means a customer was told something untrue about money or commitment.\n\n**Usually not:** analytics events, logs, cached derivations, session data, and anything reconstructable from another source.\n\nMany systems apply it selectively — synchronous for the transactional core, asynchronous for everything else. That gets the guarantee where it matters without paying latency on every write in the system.\n\nGeographic placement is the other lever. Synchronous replication within a region or availability zone is cheap enough to be routine; extending it across continents is not. A common shape is synchronous locally for zero-loss failover within a region, plus asynchronous to a distant region for disaster recovery with an accepted loss window — see [point-in-time recovery](/blog/point-in-time-recovery-2026) for what that window means in practice.\n\n## Common mistakes\n\n- **One synchronous replica.** Its failure blocks writes.\n- **Cross-region synchronous by default.** Latency on every commit.\n- **Applying it to all data uniformly.** Paying for a guarantee most data does not need.\n- **Not knowing whether automatic degradation is enabled.** You may not have the guarantee you think.\n- **Ignoring the throughput effect.** Longer commits mean fewer per second.\n- **Assuming it protects against everything.** It addresses failover loss, not corruption or accidental deletion.\n- **No monitoring of replica confirmation latency.** Slow confirmation degrades every write.\n\n## FAQ\n\n**How much latency does it add?**\nRoughly the network round trip to the replica plus its durable write. Small within a datacentre, substantial across regions. Measure on your topology.\n\n**Does it protect against accidental deletion?**\nNo — a deletion replicates faithfully. That is what backups and point-in-time recovery are for.\n\n**Can I have both?**\nYes, and it is common: synchronous to a nearby replica for zero-loss failover, asynchronous to a remote one for disaster recovery.\n\n**What if all synchronous replicas are unavailable?**\nDepending on configuration, writes block or the system degrades to asynchronous. Knowing which your system does, before it happens, matters.\n\n## Where to go next\n\nFor the asynchronous default and its lag, read [replication lag](/blog/replication-lag-explained-2026). For recovery beyond failover, [point-in-time recovery](/blog/point-in-time-recovery-2026), and for the consensus-based approach, [Raft consensus](/blog/raft-consensus-explained-2026).","hue":302,"metaTitle":"Synchronous Replication: Latency for Durability","metaDescription":"How synchronous replication removes the failover data-loss window, what it costs in write latency, and how quorum configuration avoids blocking on one replica.","keywords":["synchronous replication","zero data loss failover","commit latency","quorum commit","replication durability","rpo zero","cross region replication","database operations 2026"],"tldr":["**Every commit waits for a replica** — which adds a round trip to write latency.","**It eliminates the failover data-loss window** — that is the entire point.","**A slow or unavailable replica can block writes** — so quorum-based configuration matters.","**Cross-region synchronous replication is expensive** — the round trip is on every commit.","**Skip:** synchronous replication for data where losing a few seconds on failover is acceptable."],"readTime":"4 min read","wordCount":784},"related":[{"slug":"logical-replication-explained-2026","title":"Logical Replication: Replicating Changes, Not Blocks","excerpt":"Physical replication copies a byte-identical database. Logical replication streams row changes, which makes selective replication and cross-version upgrades possible — with sharper edges.","category":"code","date":"January 2, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":320},{"slug":"replication-explained-2026","title":"Replication explained in 2026: how databases stay in sync across nodes","excerpt":"Database replication keeps copies of your data on multiple servers for availability and read scaling. Here is the practical 2026 guide to getting it right.","category":"code","date":"April 7, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":321},{"slug":"quorum-reads-explained-2026","title":"Quorum Reads: Buying Consistency With Latency","excerpt":"Reading from one replica is fast and may return stale data. Requiring several replicas to agree costs latency and gives you a guarantee about what you read.","category":"code","date":"January 19, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":300}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"reits-investing-guide-2026","title":"REIT investing guide 2026: types, tax treatment, and the picks worth holding","excerpt":"How REITs work in 2026, why they sit in a weird tax bucket, and the funds and individual REITs that actually deserve a spot in your portfolio.","category":"finance","date":"January 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":285},"older":{"slug":"treasury-bills-vs-cds-2026","title":"Treasury bills vs CDs in 2026: which one wins for cash savings","excerpt":"T-bills vs CDs in 2026 — which actually pays more after taxes, where to buy each, and when one beats the other.","category":"finance","date":"January 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":290}}