[advisedwang]

This sounds like a very direct approach to linearizability - just put everything in a linear order.

But this includes READ operations too! You have to get global consensus for every read! Most distributed systems have additional complexity and latency on write paths so that reads can be completely local. If you can accept slow read operations this seems like a great trade off, but I think that is going to relegate this to niece usage.

[aabhay]

The article says that if your read hits a master there’s no consensus needed. Perhaps I read wrong

[advisedwang]

The system seems to have no master or leader at all. Where in the article did you get that reads from a master have no consensus?

Of course, you could build database that uses meerkat to do leader election, and then neither reads nor writes need to go through the consensus algo. But then you've basically just reproduced conventional distributed db, and you're back to the timeout problems this was supposed to solve.

[aabhay]

> We chose a different consensus algorithm for Meerkat, called QuePaxa, that aims to avoid the “tyranny of timeouts” imposed by protocols like Raft. QuePaxa is a subtle protocol, but here are the highlights. A client can contact any replica, and that replica can drive consensus for the latest slot. There is a leader, but it is not required — its only advantage is that it can drive consensus with fewer round trips (one) than other replicas (3+). Critically, clients are free to contact multiple replicas concurrently for the same proposal, to increase the chance of the proposal being successful. Concurrent proposals do not destructively interfere: replicas work together to decide one of the proposed values.

[danielmeskin]

They say they have leaders but don’t need them