4 ms·
Really, you don't want to drop problems like consistency, transactional reasoning, data loss, ... on the head of an application developer. They should be able t
by toolslive 13y ago
Really, you don't want to drop problems like consistency, transactional reasoning, data loss, ... on the head of an application developer. They should be able to have a simple, idealized view on a database or key value store; otherwise you risk their sanity.
- nutjob2 13y agoI think the point is that you sometimes can't deliver it, so you give them a slightly less general or idealized abstraction to work with. The "head in the sand" algorithm isn't always reliable.
- vidarh 13y agoI'd argue that if you don't make application developers consider these things, then you risk their sanity when they have to deal with the fallout. They need to understand the tradeoffs, and be able to decide which guarantees are important when.
- kstrauser 13y agoExactly this. I wrote a blog (at https://www.crittercism.com/blog/scaling-with-eventual-consistency/ https://www.crittercism.com/blog/scaling-with-eventual-consi...) about why my company designs for eventually consistent stores from the beginning. There are a lot of use cases - and the number is growing as companies deploy large, scaleable systems - where a consistent store just isn't practical or even needed. You can't just use an eventually consistent store as an ACID system and expect it to work, and it's almost always a Really Bad Idea to try to implement ACID on top of EC. Understand how your database works and design to its strengths instead of trying to pretend that its weaknesses don't exist.
- Terr_ 13y agoand be able to decide which guarantees are important when. This is why I like the idea of Aggregate Roots from domain-driven-design. The boundary is clear in your object model.