3 ms·
> The evil CAP theorem enters the town here. Consumers want things to work fast, it doesn't fit the decentralized approach. I think we have to distinguish 'dec
by jeswin 6y ago
> The evil CAP theorem enters the town here. Consumers want things to work fast, it doesn't fit the decentralized approach.
I think we have to distinguish 'decentralized' from 'distributed' in this case. In a decentralized approach we reduce (by many orders of magnitude) the size of data we're dealing with. Locally installed/browser-based applications only have to deal with data that's created by, or directed at that user (and locally stored).
Add: For a number of applications, hard consistency guarantees are overkill. You could totally live with eventual consistency (some don't even need that). In fact, other than e-com and banking I can't think of any of my daily-use apps needing such guarantees. And indeed, decentralized data storage is a bad fit for banking and commerce.
- eternalban 6y agoNetwork hops cost time regardless of payload size. Distributed consensus (which is what is required for a “decentralized” system) requires interaction between distinct nodes. You should note most consensus algorithm designs start with sharing a single ‘register’ (or ‘value’). Most banks were doing “decentralized” relaxed consensus from the beginning of “banking”. Local office accepts your deposit of your check. “Funds available next day”. Because by “next day” they have confirmation from counter party for the funds.
- aabbcc1241 6y agoIn your example, bank system can be seen as employing eventual consistency approach.