Eventual consistency: what to get right first

There is no clever trick in this one, just a handful of decisions worth making deliberately. If you only fix one thing about eventual consistency this quarter, make it the first item below.

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.

Start here

Users notice inconsistency long before your monitoring does. 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.

Then this

Decide which reads must be immediate and which can lag. This is the sort of thing that compounds, quietly, in both directions. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Eventually

Explain the delay in the interface rather than hiding it. In practice this is a scheduling problem more than a technical one. Budget a little time for it every quarter and it never becomes a project of its own.

What this looks like day to day

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
• Decide which reads must be immediate and which can lag — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.