[evanweaver]

Since FaunaDB is multi-master (or masterless, if you prefer), there is no failover step per se. Any region in the cluster can receive writes if it is part of the majority partition, and any region can serve consistent reads even if it's temporarily in a minority partition.

You don't have to set any priorities, and partition events don't change commit latency for the cluster majority.

Currently FaunaDB drivers use geo DNS in route53 to automatically find the closest region, although you can pin to specific regions if you know the cname. If that region doesn't own the data for the logical database in question, FaunaDB forwards the request internally.

In the future, drivers will maintain their own ϕ accrual failure detectors and make faster and smarter routing decisions than DNS can provide.

[redwood]

How do you handle write conflicts?

[evanweaver]

Transactions are strictly serialized; the paper explains how this works the best: https://fauna.com/pdf/FaunaDB-Technical-Whitepaper.pdf

We use a single-phase model inspired by Calvin, rather than Spanner's two-phase model. The tradeoff is that interactive transactions (like in SQL) are not supported, but overall latency and throughput are much better.