You can use Paxos. There will be some partitions that can cause an outage, but this is only the case when there is no majority of nodes that can communicate with each other, which in practice means you are exposing yourself to a vanishingly small risk.
3 rounds of communication to reach consensus for every transaction? Off the cuff, it seems like that would hinder the performance. I haven't tested it, though..
It doesn't have to be per transaction, it could be for a batch of transactions. There are also optimizations like multi-paxos that can reduce the number of round trips.
Presumably they sacrifice availability? If your network is only partitioned 1/1000 of the time and you only need 99.9% uptime, that would be a viable approach.
That system works by giving up interactive transactions. But the foundationdb page claims to have interactive transactions, so it must be doing something else.
Calvin requires all transactions to be executed fully server-side and sacrifices the freedom to non-deterministically abort or reorder transactions on-the-fly during execution. In return, Calvin gets scalability, ACID-compliance, and extremely low-overhead multi-shard transactions over a shared-nothing architecture.
The comments on that post are pretty interesting, too.
FoundationDB transactions are true interactive sessions, unlike distributed databases that require stored procedures. This means that client code can make an iterative series of reads and writes over the network to execute complex transactions.
