Mike Stonebraker

Why did they pursue eventual consistency

Okay, well, the idea is that you have an East Coast database and a West Coast database and they're replicas.

So you want them to be the same.

If you say, I'm going to do a transaction, I'm going to decrement by one the number of widgets in the West Coast warehouse.

Then I'm going to, before I commit that transaction, I'm going to update the East Coast warehouse, pay a message over and back to update it.

And then to make sure everything goes well, it takes another round trip of message to make sure that both of them actually do the commit correctly.

So it's expensive to do a distributed commit.

And it still is.

And so the idea was, well, you do the West Coast update, you decrease the widgets by one, you just send a message asynchronously and not in a transaction so that eventually the East Coast warehouse gets decremented by one.

So meanwhile, if you're on the East Coast, you decrement foodstuffs by one, you send an asynchronous message, eventually the West Coast gets it, and eventually everything settles out.

So if you're allowed to go below zero,

then what will happen is if the East Coast guy and the West Coast guy simultaneously sell the last widget, then eventually the state of the warehouse will be minus one and somebody won't get their widget.

And so if you're allowed, like Amazon to say, usually ships in 24 hours, then maybe you're allowed to oversell.

But most enterprises can't do that.

And so eventual consistency just doesn't work.

So we talked a million hours ago about referential integrity.

So referential integrity in a sales system is integrity constraint is stock is greater than minus one.

And that fails.

with eventual consistency.

And so Jeff Dean of Google finally figured that out.