Eventual Consistency

Question

I am in the early stages of design of an application that has to be highly available and scalable. I want to use an eventual consistency data model for this for a number of reasons. I know and understand why this is an unpopular architectural choice for many solutions, but it's important in my case.

I am looking for real-world advice, best-practices and gotchas to look out for when dealing with distributed / document-style databases. And particularly areas around e-commerce (shopping cart style) apps that traditionally are easier to put together with a relational db.

I understand using these types of DB is challenging, but hey, Google and E-bay use them so they can't be that hard ;-) Any advice would be appreciated.

Tropous

Answer 1

If you want to have a Distributed System (that "Eventual Consistency" thing) you need people, build, maintain and to operate it.

I found that there are three classes of people which have very little problems with "Eventual Consistency":

• People with a solid background in distributed systems. They have learned about Eventual Consistency Byzantine Failures and stuff like that. If you understand that Paxos is not about holidays, you are probably one of them.
• People experienced in network programming. They might miss the theoretical background but have an intuitive understanding of asynchronity and the "no global clocks & counters" paradigm. If you own at least 8 books by Richard Stevens you are probably one of them.
• Very experienced coders which had little exposure to RDBMS. Kernel guys, people from scientific computing and the gaming industry come to mind.

All in all this people are very sought after in the job market. For example 75% or so of the academics in distributed systems leave for institutions who run big, self-designed distributed systems, e.g. the stock exchanges.

The whole thing got somewhat simpler with offerings like Hardoop, SimpleDB and CouchDB but it is still a big challenge to build something on distributed systems technology.

On the other Hand RDBMS are a very fine pice of engineering. They are well understood and expertise on them is available the job market. There are a lot of decent tools, education opportunities and lots of highly skilled experts are available to be rented by the hour. So think twice of you can't get on with a RDBMS approach - perhaps coupled with some clever cheating. I usually point students to the Lifejournal architecture.

For Distributed Databases there is much less experience. That's exactly the reason you have found so little advice so far.

If you are determined to use "Eventual Consistency" I think besides immature tools the main challenge is the mindset of everyone involved. Are your API users (coders) and application users (your employees and your customers) are willing and able to accept the inconsistency? Can you hide it from certain classes of users? We are not used to that mindset that computers are inconsistent. Something is in stock or it isn't. "Maybe" isn't an answer users expect.

Also keep in mind that "eventual" can mean a very long time to algorithm designers. For how long can you accept inconsistency?

For a shopping cart application you might want to go truly distributed: Use the Clients Browser as data store. On checkout you can submit the cart to the server side batch processing system. This means for the catalog you need read only high availability (easier) and the cart submission is a very narrow interface with no need for transactions. Later on the processing of the order has no (Soft) real time requirements and thus is easier.

BTW: Last time I checked on E-Bay architecture they where big in RDBMS but it may have changed since then. (Edit: it did change - see comments)

Muncy

I assume part of this is tongue-in-cheek: according to his own web page, W. Richard Stevens has only published seven books! – Persuasion

I laughed for some reason at the "Maybe" part... kept picturing amazon telling me it might have something in stock and I might have just been charged but they'll get back to me about it. – Hafer

@Hafer that is exactly what is happening in the background but they don't tell you unless you really are hit by a collision (two people ordering at the same time) and they can't restock fast enough. – Muncy

Answer 2

The only solution to your problem is to decide which tradeoffs in the CAP theorem are right for you, then begin implementing it.

mdorseif has a great point. There are many configurations of to what extent you trade off consistency, availability, and partitioning. You have two main options.

1. Go the route of an in-house distributed system (takes lots of expertise and research)
2. Vet and experiment with a number of distributed databases to decide what can handle your requirements as scale.

This is probably an over-simplification. A real production-ready pipeline is an eco-system. It'll at least get you on the right track.

Appnexus is an ad platform that uses hbase for very high availability and eventual consistency. They talk a lot about this here.

An article on http://highscaleability.com outlines how the New York Times implemented RabbitMQ alongside Cassandra across a WAN for fault tolerance and high availability.

MongoDB provides a great deal of flexibility in balancing consistency with availability with their implementation of write concerns. They've got excellent documentation that highlights exactly how to implement it with all the gotchas (including partitioning). They implement the two-phase commit to maintain state across the network (on their config servers).

Google has a great paper on this subject, their photon project implements a highly scalable, highly reliable system with the paxos algoritm at the heart of it alongside a few other techniques. It also happens to be very consistent (with end-to-end latency of about 10s) and fault tolerant, standing up to regional failures.

Rangel

Answer 3

All systems build on distributed computing models are build on CAP and BASE. Here the main concern is If our system provides Availability and Partition Tolerance we cannot have true consistency but we can have eventual consistency.

The idea behind eventual consistency is that each node is always available to serve requests. As a trade-off, data modifications are propagated in the background to other nodes. This means that at any time the system may be inconsistent, but the data is still largely accurate.

Source: http://www.techspritz.com/eventual-consistency-and-base-model/

Gabriel

Answer 4

How to achieve high availability and scalability using relational databases is well known and there is a vast body of knowledge out there on how to do this!

Google is a special case which does not apply to most sites, very very high volumes of queries, very very large amounts of data, and, most importantly no Service Level Agreements with most of its users. There is no correct answer to a Web search only better answers, for the average user Google is good enough, if Google misses a vital page from a search list you as a user cannot complain.

E-Bay is a rather different case, somehow they have persuaded there users and customers to accept poor service in exchange for theoretically lower prices -- good on them but this is not an option for every business.

Maledict