On Thu, May 5, 2011 at 10:45 AM, Ryan Malayter <malayter@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.herbert@gmail.com