http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660More on what's called 'CAP's theorem', which illustrates the core aspects of what one has to do when moving away from ACID towards BASE: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem I think what's essential here is that if you are coming from the ACID world (and we all are, more or less), moving towards the other end of the spectrum is not going to be easy, and requires understanding of what it is that makes the other side of the spectrum actually work. that's not: dropping the database, nor dropping one character of ACID. The article above illustrates that IMHO the best. Hope it's helpful, also for the people who think stale data is something they don't have to work with because they work with ACID databases. http://ayende.com/153122/architecture-code#comment3http://ayende.com/153122/architecture-code#comment3Sun, 08 Jan 2012 12:02:04 GMT"For example, taking something as simple as “user names are unique” would move from being a unique constraint in the database to something that needs to be able to handle those sort of things in a reasonable fashion." You can't even talk about uniqueness in the context of BASE, as you never know when the state is consistent so you can decide whether a given name N is already in use or not. In all other situations, you can't decide whether a name N is violating a uniqueness constraint: e.g. it might be the value N is also in the process of being removed, but it's only really removed when the state is consistent again, and you never know when that is. Moving to a non-acid environment has a tremendous impact on how your code should work, in every aspect: you can't 'assume' anything is valid, as there's no way you can assume at the time you perform a given action that the state is consistent. You can only see what's there, but making decisions on what's there is not said to be correct, as BASE implies that the state is in fact, not consistent. In a system which is highly volatile, it might even be so that the BASE oriented system never reaches a consistent state. Moving an acid oriented system to such an architecture is IMHO impossible, unless you rewrite / rearchitect the system around the concept of stale data / user-state==application-state from the ground up. It's a conceptual change, what you see as data is only valid for the current code, not for the entire application. Making assumptions it is (like in the uniqueness of a name) is therefore impossible to do. http://ayende.com/153122/architecture-code#comment2http://ayende.com/153122/architecture-code#comment2Sun, 08 Jan 2012 11:40:40 GMTOf course architecture is bigger than code. A slight change in the architecture means a huge change in the code, and that's why most programmers hate to make any change in their architecture once they are halfway through the project, simply because of the huge work involved. Of course, that change of architecture may save many days of work later on in the project, but the upfront overhead is scary from most developers, and if it's working, it's working!http://ayende.com/153122/architecture-code#comment1http://ayende.com/153122/architecture-code#comment1Fri, 06 Jan 2012 14:52:01 GMT