Getting started with eventual consistency
There is no clever trick in this one, just a handful of decisions worth making deliberately. A short on-ramp to eventual consistency for teams who have not touched it before.
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
What is actually at stake
Users notice inconsistency long before your monitoring does. The cost of getting this wrong is rarely visible on the day it happens. If it only works because one person remembers to do something, it does not work yet.
Your first week
- Find out what is already in place
- Decide which reads must be immediate and which can lag
- Change one thing and measure it
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. Doing this properly once is usually cheaper than doing it approximately three times.
The short version
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
- 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
If any of that sounds like a description of your current setup, it is fixable.