Hacker News Reader

I'm not too familiar with multi master replication. What happens when a request handled by server A is followed by a subsequent request that is routed to server B before server A has replicated the changes from the first request? The client would expect a certain state on the "server" given the first request but it certainly seems possible to invalidate that.

View on HN

If you attempt to update a record, you send a uuid to server B representing the document you're attempting to update; if sever B doesn't have that document yet (either because it hasn't been created on server B or because it is not yet updated to the latest changes on server B), that change will be rejected.

If you are just expecting the document to be a member of a list (say, you put an order on server A, then look for all orders belonging to a customer on server B), you're not guaranteed to see it. This is 'eventual consistency' -- in practice, you want to be sure that you can live with this as a tradeoff.

Thank you.

The google tech talk on CouchDB talks about this problem :

http://www.youtube.com/watch?v=ESDBM9-U804

54:14 in, someone asks a similar question

Reply on news.ycombinator.com