[aaronmu]

Can anyone explain why eventual consistency is so scary? The way I see it, eventual consistency is everywhere. Even in your non-distributed synchronous CRUD app. The minute you start two db transactions within one script you have eventual consistency. You have to deal with the fact that one transaction can fail and that your state can be inconsistent.

[victorNicollet]

Dealing with eventual consistency adds a lot of mental complexity to almost every feature. It turns a simple rule like "Do not allow registering an username if that username has already been registered" into an entire rulebook on what should happen if a username is registered twice. It even forces you to deal with the obvious "Once a gizmo is created, it should appear in the list of gizmos". Every part of your code becomes a potential race condition that you have to detect and handle appropriately.

You can't get rid of eventual consistency, obviously, but you can set up your system so that your code expresses rules and features in an "immediately" consistent abstraction, and the system then translates those rules and features into the eventually consistent world, by applying tactics and techniques that you would have otherwise applied manually. It's a really natural approach for programmers: automate the translation from immediate to eventual, instead of doing it yourself every time.

Of course, most of these tactics come at a cost, either of performance (we won't acknowledge the creation of a gizmo until we've propagated that creation to every server capable of rendering the list of gizmos) or of availability (the registration of your username can't be acknowledged unless the persistent consensus reflects that you're the only one who registered it). But that's fine: most of these things aren't critical enough to make it worth dealing with eventual consistency manually, and when they do become critical, it's time to go down a level of abstraction and apply immediate-to-eventual translation tactics that rely on additional assumptions about what you're doing in order to improve performance or availability.

[he0001]

> The minute you start two db transactions within one script you have eventual consistency.

Well it's all about errors (and subsequently about control and correctness). Even if you have two transactions you are able to undo the other without anyone else (readers of the system) know that it was there because something else happened just before yours. A transaction usually happens in an atomic fashion, which makes it possible to back out on something which is no more correct so you have to fail it somehow to someone which does have the ability to recover, the one who initiated the call.

Without being too philosophical, most, if not everything depends on synchronous state (fex events themselves), computing just gives the illusion of that things happens immediately. Eventual consistency is cheating, and you can do it where the events are entirely independent. Otherwise you will have side effects when events are not ordered.

JavaScript have an "asynchronous" coding style, where (red/blue) methods are put on event-loop as "events". But the events needs to executed in order (synchronously by a thread) for the program to behave correctly so you give the methods attributes (red/blue) for them to execute in an linked order. So even the asynchronous behaviour in JS relies on synchronous features for it to be correct!

[jorgeleo]

It really depends on the application. Eventual consistency means that eventually, the databases will be consistent.

Some bank transactions, for example, do not have that luxury because it might allow 2 possible answers to the same query if the eventuality has not been met.

Some trading transactions don't have that luxury either because the milliseconds that you waited for the consistency a stock might have changed its price dramatically.

It really depends on the Domain if the time to wait for the eventuality is acceptable or not.

[gregyoung1]

Bank transactions are eventually consistent. How do you think you can get an overdraft fee? Ever use a gas pump and notice it took a $1 authorization on your card then later settled for what you pumped?

Eventual consistency is not all that scary, try putting on a business hat instead of a technical one. Its about risk management.

[nightski]

Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios.

Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy.

[jorgeleo]

"Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios."

I live in the US, and if I got to the ATM and get cash on my account, I can go to my iPhone app and see the transaction and the balance updated.

Yes, there is a nightly process, but not everything is a nightly process.

"Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy."

Do you know what a hedge fund is?

[he0001]

This "lag" is there mostly because historical reasons, not technical.

[nightski]

I'd rather argue they are there for "domain" reasons. For one, banks often re-order transactions. I know my bank will process deposits first, then debits for the day. This way you are less likely to incur overdraft fees. It's also to fight fraudulent transactions. Although with the move to "real time" debit processing (which is actually two batch jobs a day) they are placing limits on the types of transactions that can be processed.

A domain that can't handle any delay in consistency is atypical in my experience. Either way you can do DDD/CQRS without eventual consistency.

[he0001]

They are there because they are used to think that way. It's conways law written all over it... There's no actual reason for them to do it. They replaced their paperwork with a system that does the same thing. Fraudulent transactions can you find without the need of summarizing it.

Yes you can do DDD/CQRS without ES but CQRS is not needed, it's just a technical construct not solving any verifiable problem. DDD on the other hand is more sane and to some extend, verifiable.

[jorgeleo]

Agree, the initial question was on eventual consistency, not on DDD.

[gregyoung1]

You will also note that they process debits in descending order to maximize possible overdraft fees at most banks ;-)

[_pmf_]

> The minute you start two db transactions within one script you have eventual consistency.

You may also have two independent items of information that have no consistency relationship or requirements.

That's why eventual consistency "works" so "well" with NoSQL: because there's an overlap between using NoSQL databases and not requiring actual consistency.