A short guide to eventual consistency

Most teams know this matters. Fewer have decided who owns it. Everything we would tell a client about eventual consistency in the time it takes to drink a coffee.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What it costs to ignore

Users notice inconsistency long before your monitoring does. None of that requires a large budget, only a decision and someone to own it. Budget a little time for it every quarter and it never becomes a project of its own.

The practical version

Decide which reads must be immediate and which can lag. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.

What to watch for

Explain the delay in the interface rather than hiding it. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. 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

Worth checking on your own setup before it becomes someone else's problem to fix.