Thanks for submitting! The nice thing about our publishing model is that I can edit the document with suggestions, so send them my way!

Thank you @marcua for writing this informative and useful chapter.

Check out

http://scalien.com

or

http://github.com/scalien/scaliendb

for a replicated, scalable (sharding) database built around strong replication (Paxos). Google's latest database called Megastore is also using Paxos and they seem to be moving away from eventual consistency.

"If the data grows past the capacity of one server, then the tables in the database will have to be partitioned across computers. To avoid JOINs having to cross the network in order to get data in different tables, we will have to denormalize it. Denormalization stores all of the data from different tables that one might want to look up at once in a single place. This makes our database look like a key-lookup storage system, leaving us wondering what other data models might better suit the data. "

I have a question here. Denormalization increases redundancy of data, thus also increasing space requirements. So how is denormalization a solution to low server capacity?

Sometimes I wonder if the claims made by people that banks require ACID are rooted in any kind of experience or fact.

ACID isn't a banking issue, it's an issue in any database where data integrity is important. Having written administration software for life insurance companies, you can be sure that we designed our software to rely on ACID semantics.

Without transactions, correctly writing the software would have been far more difficult, especially in situations where you need to rollback a transaction that is partially completed because of system errors.

Even Google has admitted that they wish they had built transaction support into BigTable from the start. Instead each internal group tried to create their own hack.

Banks aren't ACID though. You can still deposit a check, withdraw against it, then have the deposit fail later.

How do we deal with inconsistency and failed transactions in the real world? Customer service. (anecdotes stolen from Eric Brewer's distributed coherency talk at a Riak event)

Bingo. Banks aren't ACID at all. In actuality, the datastore of record for internal bank transactions usually looks more like a continuous transaction journal with two account numbers and an amount. The snapshot balance of any account isn't much more than a cache computed value. There are, of course, layers and layers of complex systems built on-top of this, but the actual base of all of it is very simple, old school, batch process technology. The original eventual consistency.