2

I'm reading about eventual consistency in couchDB. I'm somewhat confused by the term and its consequences on an application.

Let's say I'm building a distributed e-commerce website where monetary transactions are critical. There could be online auctions running and people bidding on them in real time. Will using a eventual consistent DB such as couchDB be a wrong solution? Should I favor a more consistent solution such as a relational database?

Is couchDB suitable for something non critical such as a social network where one wouldn't mind if his news feed isn't up to date or when comments on his posts are somewhat delayed by few seconds?

Update

I'm talking about building a distributed system. I think in case of a single server nothing of this will matter.

Community
  • 1
Songo
  • 6,548
  • 4
  • 48
  • 89
  • 1
    "real time" and "eventual" don't sound like they mix well... – Marjan Venema Jan 26 '14 at 16:38
  • 1
    will the IRS be ok with "eventually consistent" Accounting practices? – Mike Graf Jan 26 '14 at 17:08
  • IMHO - a bid is not the same as a bank wire transaction. It's a "potential" monetary transaction. Is using both an option? – JeffO Jan 27 '14 at 15:26
  • Eventual consistency is really good for recording transactions, where there will be no concurrency in writing. If you have concurrency in writing, then it can still work, but is not quite so simple. – Michael Shaw Jan 27 '14 at 15:33
  • @JeffO well I'm still trying to discover what couchDB could be used for. I hear a lot of people talking about how couchDB is better for distributed systems, but I don't know why. How could one use a hybrid approach? – Songo Jan 27 '14 at 15:34

2 Answers2

2

The eventual consistency part has to do with distributed systems-- that is, when there is more than one copy of the data and it needs to be consistent. It's basically the difference between synchronous and asynchronous replication.

So, it's not an issue if you have a single server. It's also not an issue if your system (Couch) has a synchronous mode of operation.

There's also no guarantee that conventional databases wouldn't succumb to this problem (think MySQL replication where slaves are lagging behind the master).

So the answer to your question is: it depends.

RibaldEddie
  • 3,168
  • 1
  • 15
  • 17
  • To be specific, in a real distributed system, it's more like multi-master replication where different writes could be going to different servers, and less like conventional master-slave replication where all writes go to a single server. – RibaldEddie Jan 27 '14 at 17:26
0

Think of it this way:

You can use eventual constancy to record and capture each users bids. The fact that the database will take a few mSec to share the bids around is not material.

You can also have a stand alone process that decides which auctions have finished, and which bid won each auction. This process needs to allow a few seconds for eventual consistency to complete so that it is highly likely to have a complete view of all bids. However its decision needs to be final.

The users then can see who has been awarded the auction as per normal. The fact that some users may see this a few mSec earlier than the others again is not material, the key is that if they keep refreshing their page (or receive push messages) they will see it when the replication has made it to their database server.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36