A practical checklist for eventual consistency

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Run through this the next time eventual consistency comes up.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Doing this properly once is usually cheaper than doing it approximately three times.

The checklist

• Users notice inconsistency long before your monitoring does
• Decide which reads must be immediate and which can lag
• Explain the delay in the interface rather than hiding it
• Someone is named as the owner
• There is a date to review it again

What it costs to ignore

Users notice inconsistency long before your monitoring does. The teams that handle this well are rarely the ones with the biggest budgets. If two people in the business would answer this differently, that gap is the actual problem.

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
• 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 any of that sounds like a description of your current setup, it is fixable.