“Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.” [source]

Distributed state

When we build distributed systems, there are times that state is distributed across our architecture (e.g. when we favour availability over consistency, e.g services have a copy of the data they are consuming vs requesting it from another service). This means data across your architecture in theory will be eventually consistent and at times the state will be inconsistent (as data is replicated across your architecture).

Users performing async actions

Another common pattern is when users perform async operation. A command is sent to perform an action, and an async operation kicks in to process the action. The user then goes to read the information but it’s not complete yet or returns old stale information, this means the task or data has not yet been replicated from where the user/api is reading it from.

When data is inconsistent it can affect your users experience (users reading their own writes), so it’s worth considering UX patterns you can introduce to help (e.g webhooks back to client). Also, it’s worth asking yourself does your business mind if these tasks are async and eventually consistent? Like most things, trade-offs need to be considered.

When building EDA applications, you will naturally find yourself dealing with patterns and experiences that are eventually consistent, it’s worth keeping that in mind and creating or exploring patterns to help if you need to manage it better.

Extra Resources

• CAP theorem - Interesting theory about consistency, availability and partition tolerance, and that distributed data store can only provide two of the following.
• Trade-offs of event driven - More information from AWS to tell us about the trade-offs when going event-driven, more information on Eventual consistency