FaunaDB uses Calvin, a transaction protocol developed by Daniel Abadi. Their blog post explains it nicely, after a bit of a slow start:<p><a href="https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol" rel="nofollow">https://fauna.com/blog/consistency-without-clocks-faunadb-tr...</a><p>But in summary:<p>1. A 'transaction' is a self-contained blob of code which reads input, does deterministic logic, and writes output (so not like a traditional RDBMS transaction, where the application opens a transaction and then interleaves its own logic between reads and writes)<p>2. When a transaction arrives, the receiving node runs it, and captures the inputs it read, and the outputs it wrote<p>3. The transaction, with its captured inputs and outputs, is written to a global stream of transactions - this is the only point of synchronisation between the nodes<p>4. Each node reads the global stream, and writes each transaction into its persistent state; to do that, it repeats all the reads that the transaction did, and checks that they match the captured input - if so, the outputs are committed, and it not, the transaction is aborted, and retried<p>The key idea is that because the process is deterministic, the nodes can write transactions to disk independently without drifting out of sync.<p>It's pretty neat. And it's exactly what Abadi wrote about a couple of months ago:<p><a href="http://dbmsmusings.blogspot.com/2019/01/its-time-to-move-on-from-two-phase.html" rel="nofollow">http://dbmsmusings.blogspot.com/2019/01/its-time-to-move-on-...</a><p>This is also what VoltDB does (which Abadi worked on, along with Michael Stonebraker):<p><i>As an operational store, the VoltDB “operations” in question are actually full ACID transactions, with multiple rounds of reads, writes and conditional logic. If the system is going to run transactions to completion, one after another, disk latency isn’t the only stall that must be eliminated; it is also necessary to eliminate waiting on the user mid-transaction.</i><p><i>That means external transaction control is out – no stopping a transaction in the middle to make a network round-trip to the client for the next action. The team made a decision to move logic server-side and use stored procedures.</i><p><a href="https://www.voltdb.com/product/data-architecture/no-wait-design/" rel="nofollow">https://www.voltdb.com/product/data-architecture/no-wait-des...</a><p>It's also similar to, although categorically more sophisticated than, the idea of object prevalence, which is now so old and forgotten that i can't find any really good references, but:<p><i>Clients communicate with the prevalent system by executing transactions, which are implemented by a set of transaction classes. These are examples of the Command design pattern [Gamma 1995]. Transactions are written to a journal when they are executed. If the prevalent system crashes, its state can be recovered by reading the journal and executing the transactions again. [...] Replaying the journal must always give the same result, so transactions must be deterministic. Although clients can have a high degree of concurrency, the prevalent system is single-threaded, and transactions execute to completion.</i><p><a href="https://web.archive.org/web/20170610140344/http://hillside.net/sugarloafplop/papers/5.pdf" rel="nofollow">https://web.archive.org/web/20170610140344/http://hillside.n...</a>