4 ms·
> 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
by runT1ME 9y ago
> 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.
- burntsushi 9y agoI'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.
- holoway 9y agoHabitat 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.