A single-writer, single-replica setup is fine until the primary goes down mid-transaction. For most apps, losing a few seconds of writes during failover is annoying. For a ledger, it's unacceptable — a lost or duplicated transaction is a lost or duplicated payment. I needed a write path that could survive a node failure without silently losing data or double-counting money.
What Quorum Actually Buys You
A quorum write requires acknowledgment from a majority of replicas (in my case, 2 of 3) before a write is considered committed. This means the system tolerates one node failure without any data loss, and I get a mathematically guaranteed overlap between the write quorum and read quorum — so a read can never miss the latest committed write. The tradeoff is latency: every write now waits on the slowest of two acknowledging nodes, not just one.
Implementation Notes
I implemented this at the application layer rather than relying on Postgres's built-in replication, since I needed fine-grained control over which nodes counted toward quorum and how conflicts got resolved. Each write goes through a coordinator that fans out to replicas, waits for 2/3 ACKs, and only then returns success to the caller. Still tuning the timeout values — too aggressive and healthy nodes get flagged as failed under load.