Synchronous Replication

In 2012, Knight Capital deployed a buggy trading algorithm that executed millions of errant trades in 45 minutes, losing $440 million. But imagine a different nightmare: what if the database recording those trades crashed, and the async replica was 10 seconds behind? You'd have 10 seconds of trades with no record of what happened. Regulators would have a field day.

Financial systems, healthcare records, legal documents. There are domains where "we might lose the last few seconds of data" is not a valid sentence. Synchronous replication exists for these cases. The write doesn't succeed until at least one replica confirms it has the data. If the primary dies one millisecond later, the replica already has everything.

It's slower. Sometimes significantly slower. But when the alternative is explaining to a banking regulator why customer transactions vanished, the latency is worth it.

The flow is almost identical to async, with one critical difference at step 3:

1. Client sends a write to the primary
2. Primary writes to its local WAL and storage
3. Primary sends the WAL entry to the replica(s)
4. Primary waits until at least one replica confirms it wrote the data to its own WAL
5. Only then does the primary confirm the write back to the client

That wait in step 4 is everything. It means the write latency now includes the network round trip to the replica plus the replica's disk write time. If your replica is in the same data center, that adds maybe 1-5ms. If it's across the country, that's 30-70ms. If it's across the ocean, 100-200ms.

The guarantee: At the moment the client gets "success," the data exists on at least two machines. If either one dies, the other has the data. Zero data loss during failover, as long as both machines don't die simultaneously.

The cost: Every write is slower by the replica round-trip time. Under heavy load, this can tank write throughput because the primary is constantly waiting for confirmations.