Hacker News new | ask | show | jobs
by jorgeleo 3212 days ago
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.

2 comments

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.

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.

"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?

This "lag" is there mostly because historical reasons, not technical.
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.

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.

Agree, the initial question was on eventual consistency, not on DDD.
You will also note that they process debits in descending order to maximize possible overdraft fees at most banks ;-)