Eventual consistency, explained without the jargon

There is no clever trick in this one, just a handful of decisions worth making deliberately. Here is eventual consistency without the vocabulary that usually surrounds it.

Most systems fail at the seams rather than inside any one component. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Users notice inconsistency long before your monitoring does. The cost of getting this wrong is rarely visible on the day it happens. Budget a little time for it every quarter and it never becomes a project of its own.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The teams that handle this well are rarely the ones with the biggest budgets.

Decide which reads must be immediate and which can lag. It is worth being explicit about, because assumptions differ quietly. Check it against what you would want a competitor's site to get wrong.

Turning this into a decision

Explain the delay in the interface rather than hiding it. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

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
• Explain the delay in the interface rather than hiding it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.