Hacker News Reader

Comment by runT1ME | Hacker News Reader

You need a server, which is a single point of failure. If you want redundancy, you now need a quorum in the event of a split brain. CRDTs have the advantage of not needing a quorum in event of a split brain. There is no way to 'lose' information. In addition to being resilient to network split brain, this allows you to make performance gains at the sacrifice of consistency, where you could buffer your updates to other nodes.

Operation based CRDTs do seem more limiting compared to State Based though, so you're at the mercy of your data structure being able to be represented as a CRDT.

View on HN

Sure, but let's say I was OK with a single point of failure. Or let's be more specific and say my central server is a PostgeSQL instance.

> In addition to being resilient to network split brain, this allows you to make performance gains at the sacrifice of consistency, where you could buffer your updates to other nodes.

My scheme allows this too, no?

> Sure, but let's say I was OK with a single point of failure.

I cannot imagine designing a system for production use where anyone is OK with a single point of failure being a single instance of a machine. I mean if we're playing hypothetical games you don't need a distributed system either, just get one giant instance and put everything on it.

I'm trying to distill the design down to its essential components, and then figure out when it will break. If you're going to stick on this point, then let's imagine I have a PostgreSQL setup with replication, such that if any one fails, I can fall back to another. I primarily want to put this in the context of what problems folks are solving with operational CRDTs to get a sense of the scale that requires them.

> I mean if we're playing hypothetical games you don't need a distributed system either, just get one giant instance and put everything on it.

I guess the requirements need to be more explicitly stated. You need to at least be able to support multiple simultaneous clients interacting with the system, where any client could disconnect for some period of time.

Habitat uses some simple data structures that are basically CRDTs. We used them because they made the user experience better (not needing infrastructure other than the gossip itself). One thing I learned early on that journey was that the more specific your use case, the easier a fully distributed model is. As soon as you need generic primitives a-la etcd or zookeeper, everything gets orders of magnitude harder.

Reply on news.ycombinator.com