3

I've heard people talking about "eventual consistency" (for example in this question and this answer).

What is "eventual consistency"? How does it compare to "transactional consistency"? When does it happen?

What sort of impact does eventual consistency have on the design of systems which are affected by it? How can it be mitigated to provide a good user experience?

Community
  • 1
Benjamin Hodgson
  • 4,488
  • 2
  • 25
  • 34
  • 2
    The questions look like they've been copied and pasted from some homework text. – Giorgio Jan 02 '15 at 21:54
  • They were not. How would you propose rephrasing the question? – Benjamin Hodgson Jan 02 '15 at 21:55
  • Let's wait a few minutes to see if some more experienced user has any suggestions. – Giorgio Jan 02 '15 at 21:58
  • 2
    Questions that roll up a lot of little questions are really hard to answer. Also, eventual consistency is a really broad area, so you might benefit from some web crawling to narrow it down. These are all good questions, but maybe not for here. – sea-rob Jan 02 '15 at 21:58
  • For example, I'd kind of be interested in the intersection between eventual consistency and CQRS, but that's just a small facet of what you've asked here. However, I believe CQRS and eventual consistency are orthagonal, so a little research on your own would bear out whether or not even that question has merit. – sea-rob Jan 02 '15 at 22:02
  • I usually hear eventual consistency talked about in relation to CQRS, but that could just be because of where I work – Benjamin Hodgson Jan 02 '15 at 22:07
  • We used to have a thing called Distributed Databases where some PCs would store data retrieved from a server. They could then send changes. Obviously, this was an Eventually Consistent system, because the process of each PC connecting to the server and doing its send/receive was asynchronous. Someone might not do their sync for days, and be looking at old data, then try to submit a change using the old data and have it fail. This is easy to manage using timestamps and allowing multiple compatible changes. The 'eventual' part was not even thought about, because there was no alternative then. –  Sep 26 '17 at 16:36

2 Answers2

15

What is "eventual consistency"? How does it compare to "transactional consistency"? When does it happen?

Consistency models describe how a system (nominally a distributed system) responds to change.

  • In an eventually-consistent system, all nodes will eventually have a consistent view of the overall system state. However, there will be a period of time after the initial change in which different nodes will have different views of the state.
  • In a transactionally-consistent system, the point at which all nodes have a consistent view of state is defined by applying transactional boundaries to the change. Either the transaction completes or it fails, and the thing that initiated the change will know which has happened. All nodes will see the same state both before and after the transaction completes.

Here's a real-world example: you go to your bank and deposit a check. You have initiated a change to two accounts: your account and the account of the person who wrote (issued) the check.

  • In a transactionally-consistent system, the addition of funds to your account happens at the same time as the removal of funds from the issuing account. At no point will the funds appear in both accounts (or in neither).
  • In an eventually-consistent system, the funds might be added to your account before they are debited from the issuing account. During some window of time, both accounts may show the added funds.

That latter scenario sounds very scary to most people. But it was exactly how the US financial system worked throughout the 20th century: you deposited a check, and that check was physically transported to the issuing bank, which then debited the money from the customer's account.

When you design your system to be eventually consistent, you need to be aware of problems that can arise from different nodes having different views of the world, and take steps to compensate. However, this compensation can lead you down a rat hole if you're not careful; it's easy to spend exorbitant amounts of effort to prepare for the case where the airliner carrying the not-yet-cleared checks crashes and burns.

On the other hand, with a transactionally-consistent system, you have to be ready for the failure of any node (or communications channel) to mean the failure of the entire system (or at least of every attempted transaction).

kdgregory
  • 5,220
  • 23
  • 27
1

Long story short:

Transactional consistency, is when you load aggregate, change it and save it again in single transaction

thats transactional consistency

When you need multiple aggregates to be involved (changed), some business process may involve stuff even from different bounded context. You transactionally update local aggregate and store event, publish event about your change, then (asynchronously: e.g. via message broker) second bounded context (or even local) will receive event about such change and eventually updates second aggregate.

thats eventual consistency, because eventually (not atomically) will consistency occurs in some time..It may be millis, it can be hours/days..

Slimer
  • 217
  • 1
  • 9