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?

  • 2
    The questions look like they've been copied and pasted from some homework text.
    – Giorgio
    Commented Jan 2, 2015 at 21:54
  • They were not. How would you propose rephrasing the question? Commented Jan 2, 2015 at 21:55
  • Let's wait a few minutes to see if some more experienced user has any suggestions.
    – Giorgio
    Commented Jan 2, 2015 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
    Commented Jan 2, 2015 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
    Commented Jan 2, 2015 at 22:02

2 Answers 2


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).


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..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.