Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
First, if you haven’t heard of
Eric Brewer’s CAP theorem, it basically states that you can must choose two of three:
- Consistency
- Availability
- Partition Tolerance
CQRS doesn’t solve CAP issues, however it allows you to decide independently what is important on both read and write side.
For example, you could assume a systems would be ACID (
Atomic,
Consistent,
Isolated,
Durable) compliant on the write/domain site and BASE (
Basic
Availability,
Soft-State,
Eventually Consistent) on the read side.
Eventual consistency is something that requires a change of mindset. Because of our heavy use in ACID compliant databases, thinking about possibly having stale data blows our mind.
There are two important points about I want to make about eventually consistent data.
- The data isn’t wrong. It’s old. There is a big difference here. The data you may be consuming may not be up-to-date, however it was correct at one point in time.
- In the real world, we use stale data all the time.
A good example, from
Greg Young, was if you read the newspaper/website and notice some statistics on the unemployment rate, this is obviously stale data. If those stats were a a week old, would this matter? How much of a difference would a week make to unemployment rate? Probably not much. However, there are scenarios where you want to be much closer to actual, and in these cases define an SLA.
The point is, in many situations, eventually consistent data is acceptable.