Does the leader wait?
When the leader saves a write, does it wait for a follower to confirm before telling your user it worked?
That one question is the whole difference between synchronous and asynchronous, and it decides whether losing the leader can lose data you already promised was safe.
Asynchronous is what you get by default nearly everywhere. The leader saves locally, answers immediately, and sends the change to followers whenever it gets round to it.
Writes run as fast as a single machine, and a slow or dead copy costs you nothing. The bill comes due during failover. Whatever the copy had not received when the leader died is gone, even though your user was told it was saved. When the copies are milliseconds behind that window is small. It is never zero.
Synchronous, and what it costs
Synchronous makes the leader wait until at least one follower has the write on disk before answering. Now the data lives on two machines before anyone is told it exists, and promoting that follower loses nothing.
You pay in two ways. Every save takes a round trip more, a millisecond or two in the same building and 80 or more across an ocean. And you have coupled two machines: if the follower you wait for dies or stalls, the leader must either freeze all writes or quietly drop the guarantee. Real systems soften that by waiting for any one of several candidates rather than one specific machine.
Decide per system, and honestly per table. A payment ledger, or anything you could not rebuild from somewhere else, deserves a synchronous copy, ideally nearby so the latency tax stays small.
Click tracking does not. Postgres lets you flip this per transaction, a rare and useful knob: one database, both answers, chosen by how much the write matters.
Worked example
Owen's team runs the orders database async-replicated across two availability zones, lag typically 200 to 900 ms. One Tuesday the leader's storage volume fails outright. Failover promotes the replica in 40 seconds, which sounds like a win until reconciliation: the replica was 800 ms behind at the moment of death, and 14 orders that customers saw confirmed, with confirmation emails sent, do not exist in the database. Support spends two days rebuilding them from Stripe webhook logs and one furious customer thread. The fix is surgical rather than global: orders and payments move to a synchronous standby in the same AZ, adding 1.5 ms per commit, while the analytics and events databases stay async, because losing a second of clickstream is nobody's incident.