Signs it is time to revisit eventual consistency

This is one of those topics that looks small until it costs you something. A few signals that eventual consistency is due some attention.

Most systems fail at the seams rather than inside any one component. It rarely shows up as a line item, which is exactly why it slips.

The signals

• Nobody can say when it was last reviewed
• The answer depends on who you ask
• Users notice inconsistency long before your monitoring does
• Decide which reads must be immediate and which can lag

Where to start

Explain the delay in the interface rather than hiding it. The reasoning matters more than the rule, because the rule has exceptions. It is the sort of thing that looks like polish right up until it costs you an enquiry.

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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.