5 ms·

> The most popular consumer apps (FB, LinkedIn, blogs, photo sharing, goal trackers, slack, basecamp etc) shouldn't be centralized in this fashion The evil CAP

by viach 6y ago

> The most popular consumer apps (FB, LinkedIn, blogs, photo sharing, goal trackers, slack, basecamp etc) shouldn't be centralized in this fashion The evil CAP theorem enters the town here. Consumers want things to work fast, it doesn't fit the decentralized approach. > Databases we have today aren't designed for the kind of consumer applications we use today Consumers don't really care what kind of database do you use. They want to open the page and click the button, quick, now.

pdimitar 6y ago
You are correct but part of this can be alleviated by aggressive caching by the client devices and delayed (optimistic) updates -- to a large extent though. Doesn't apply to all problems in this space.
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 ago
  Network 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 ago
    In your example, bank system can be seen as employing eventual consistency approach.
ric2b 6y ago
The C in CAP isn't required if we're assuming that there's an explicit "sync" that the user only expects to happen occasionally.

by viach 6y ago

pdimitar 6y ago

You are correct but part of this can be alleviated by aggressive caching by the client devices and delayed (optimistic) updates -- to a large extent though. Doesn't apply to all problems in this space.

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 ago
Network 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 ago
  In your example, bank system can be seen as employing eventual consistency approach.

ric2b 6y ago

The C in CAP isn't required if we're assuming that there's an explicit "sync" that the user only expects to happen occasionally.