Five mistakes teams make with eventual consistency

There is no clever trick in this one, just a handful of decisions worth making deliberately. These are the ones we run into repeatedly when we audit eventual consistency.

Most systems fail at the seams rather than inside any one component. If two people in the business would answer this differently, that gap is the actual problem.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Users notice inconsistency long before your monitoring does
• Decide which reads must be immediate and which can lag
• Never checking whether the fix actually worked

Explain the delay in the interface rather than hiding it. The reasoning matters more than the rule, because the rule has exceptions. If it only works because one person remembers to do something, it does not work yet.

Turning this into a decision

In practice

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Three things worth confirming about eventual consistency before you move on:

• Someone can say what the current setup is without going to look
• Users notice inconsistency long before your monitoring does — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.