On Thu, May 5, 2011 at 10:45 AM, Ryan Malayter <malay...@gmail.com> wrote: > > > On May 1, 2:29 pm, Jeff Wheeler <j...@inconcepts.biz> wrote: > >> What it really boils down to is this: if application developers are >> doing their jobs, a given service can be easy and inexpensive to >> distribute to unrelated systems/networks without a huge infrastructure >> expense. If the developers are not, you end up spending a lot of >> money on infrastructure to make up for code, databases, and APIs which >> were not designed with this in mind. > > Umm... see the CAP theorem. There are certain things, such as ACID > transactions, which are *impossible* to geographically distribute with > redundancy in a performant and scalable way because of speed of light > constraints.
That specific example depends on how order-dependent your consistency constraint is; you can have time-asynchronous locally ACID changes across databases which are widely separate. If your consistency requires order synchronicity across the geographic DB cluster then this is a potential epic fail, of course. The general point is valid. Being able to tell if your application *really* does require strict consistency or not, and if it requires strict ordering or not if it requires strict consistency, is unfortunately beyond most line-level system designers. A lot of people guess wrong in both directions, and either cripple the app's performance unnecessarily or end up with dangerous failure modes inherent in the architecture. -- -george william herbert george.herb...@gmail.com
