[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