Replication Protocol RPO Lab (Interactive)
Compare commit latency, throughput, RPO, and crash behavior across Async, Semi-Sync, Sync, and Quorum protocols. Sweep network RTT and replica counts to see exactly what each durability protocol costs per commit and what you lose when a replica dies.
Replication Protocol Latency Lab
Compare commit latency, throughput, RPO, and failure behavior across Async, Semi-Sync, Sync, and Quorum.
Commit Latency
3.4 ms
Max Write TPS
294/s
RPO (data loss)
~0.03s
Client ACK Path
replica RAM relay-log ack
Push RTT to 150ms and pick Synchronous: interactive writes become unusable at roughly 167 TPS. This is why cross-continental deployments prefer semi-sync or quorum (Aurora 4-of-6) instead.
How It Works Under the Hood
Replication protocol choice is a direct trade between Recovery Point Objective and write latency. Asynchronous commits ack after local fsync, fastest but with un-replicated WAL bytes lost on a crash. Fully synchronous blocks until a replica fsyncs remotely, guaranteeing RPO zero yet freezing all writes if that replica disappears. Semi-synchronous waits only for an in-memory relay-log ack with async fallback on timeout, and quorum schemes like Aurora commit after W-of-N storage nodes, so one lagging node never stalls the cluster.
Core Architectural Principles
- Async: local fsync only, ~1ms commits, RPO greater than zero on primary crash.
- Sync: pays full network RTT plus remote fsync per commit and blocks when the replica is unreachable.
- Semi-sync and quorum (4-of-6) balance durability with availability via RAM acks or majority voting.
Frame the choice as RPO versus latency: billing systems need RPO zero so I use synchronous or quorum within an AZ; feeds tolerate async. Warn about the sync failure mode explicitly: a frozen synchronous replica halts every write on the primary, which is why production prefers semi-sync timeouts or W-of-N quorums.
Zero data loss costs network round-trips per commit and can sacrifice write availability for durability.