Hacker News Reader

This is true, but comes at the cost of not being able to preserve linearity across arbitrary keys, and you are still limited by the throughput on updates to a single key.

View on HN

Assuming linearity is atomic multi-key updates:

1. There are tasks which don't require atomic multi-key updates

2. Atomic multi-key updates can be implemented on the client side (see RAMP, Percolator transactions or the Saga pattern)

3. Once the data overgrow the size of one machine you need to shard the log and at this time you're in the same situation

Fair enough, though at that point, you're layering on additional complexity and getting further away from the goal of simplicity. (And to point 3, while this is true, using a log means this problem can be dealt with a lot later, and there are solutions that don't involve giving up linearizability, such as a dedicated set of log replicas apart from data partitions, or implementing something like Calvin.)

My main point was that the deficiencies of strong-leader-based consensus protocols are overstated, and despite a (minor IMO) level of additional starting complexity, a raft-like protocol is going to be quite a bit simpler than a paxos-based protocol of equivalent capability.

Reply on news.ycombinator.com