Hacker News Reader

Comment by zzzcpan | Hacker News Reader

Well, networks are not that reliable. But you don't have to believe me, there is enough of public information about real world operations. Take Aurora paper for example, where they can't even do 2/3 quorum, but do 4/6 quorum instead and that's between datacenters they completely control with connectivity they more or less control.

View on HN

You're not wrong: networks in general aren't super reliable, and partitions are a real problem! Peter Bailis and I wrote a paper on this in ACM Queue. I've spent much of my professional life exploring the consequences of network failure on distributed systems.

That said, I don't think it's reasonable to infer that because failures occur more often than we'd like, systems based on consensus are always inappropriate for latency and performance sensitive systems. While there are minimum bounds on latency in consensus systems, there are also plenty of human-scale problems for which that bound isn't a dealbreaker. Moreover, some types of computation (e.g. updates in sequentially consistent or snapshot isolated systems) simply can't be performed without paying the same costs as consensus. Consensus can be an appropriate, and in some cases the only possible solution, to some problems.

I didn't infer they are always inappropriate, just that they are not good for latency and performance sensitive systems, i.e. they shouldn't be considered unless absolutely necessary.

Would you give some more insight into your opinion? What latency/performance are you targeting -- have you tried using a system like this to arrive at your conclusion?

Just because failure can happen doesn't mean it's frequent. For the record AWS does this to protect against correlated failure. At their scale, they assume they have some percentage of local nodes down at any given time, so have designed the system to tolerate both network partitions and local failure at the same time.

They did it for stable performance, because failures are in fact frequent. Things are much worse once you go out into the public internet, where different hosting providers communicate over all kinds of networks with all kinds of issues.

FaunaDB can tolerate the loss or partition of a minority of replicas (datacenters, AZs, or racks) in a cluster, so if you want to tolerate more concurrent failures, just add more replicas.

For example, a 7 replica FaunaDB cluster can lose 3 replicas and maintain availability for reads and writes; better than Aurora in your example.

Reply on news.ycombinator.com