Before you invest in eventual consistency
There is no clever trick in this one, just a handful of decisions worth making deliberately. Before you spend anything on eventual consistency, it is worth confirming a few things are already true.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Prerequisites
- You can describe the outcome you want in one sentence
- Someone owns it after the work is done
- Users notice inconsistency long before your monitoring does
- You have a way to tell whether it worked
Where it usually goes wrong
Decide which reads must be immediate and which can lag. This is the sort of thing that compounds, quietly, in both directions. Budget a little time for it every quarter and it never becomes a project of its own.
Explain the delay in the interface rather than hiding it. None of that requires a large budget, only a decision and someone to own it. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What this looks like day to day
Most systems fail at the seams rather than inside any one component. 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
Worth checking on your own setup before it becomes someone else's problem to fix.