Replication is how a database survives the failure of a single node. The question of whether that replication is synchronous or asynchronous is one of the most consequential architectural decisions in a financial system, and it is frequently made without a full understanding of what asynchronous replication actually risks.
What Asynchronous Replication Risks ¶
In an asynchronous replication setup, the primary node acknowledges a write to the client before the replica has confirmed receipt. If the primary fails between the acknowledgement and the replica receiving the log entry, that committed transaction is lost. The client was told the write succeeded. The data is gone. For most web applications, this is an acceptable trade-off. For a financial ledger, it is not.
What Synchronous Replication Guarantees ¶
With synchronous replication, the primary waits for at least one replica to confirm that the log entry has been written to durable storage before acknowledging the write to the client. A primary failure after that point cannot lose the transaction, because the replica holds a copy. The trade-off is latency: the round trip to the replica adds to the commit time. In a well-configured multi-region setup in Japan, with nodes in Osaka and Tokyo, that round trip adds roughly 0.3 to 0.5 ms to the commit latency.
FISC Guidelines and Data Durability Requirements ¶
The Center for Financial Industry Information Systems (FISC) publishes security guidelines for financial institutions in Japan. The guidelines on system availability and data integrity are consistent with a synchronous replication requirement for transaction data: the system must be able to recover committed data after a single-node failure without data loss. Asynchronous replication does not satisfy this requirement in the general case.
The Latency Cost Is Smaller Than It Appears ¶
A common objection to synchronous replication is that the latency cost makes it impractical for high-throughput workloads. In practice, the cost depends on the network distance between the primary and the replica. Between Osaka and Tokyo, round-trip latency on a dedicated inter-data-center link is typically 8 to 12 ms. Grit Core Lab's replication protocol pipelines multiple log entries in a single round trip, which amortizes that cost across concurrent transactions and keeps median commit latency at 0.4 ms under a sustained load of 80,000 transactions per second.
The choice between synchronous and asynchronous replication is ultimately a question of what the system is allowed to lose. For financial transaction data, the answer is usually nothing. The full capability list on this site describes how Grit Core Lab implements synchronous replication in practice.