Eventual consistency: the questions we get asked most

The version of this that works is simpler than the version most people imagine. The questions about eventual consistency that come up most often on our calls.

Most systems fail at the seams rather than inside any one component. Budget a little time for it every quarter and it never becomes a project of its own.

Do we need to care about this?

Users notice inconsistency long before your monitoring does. Getting it slightly wrong is survivable. Ignoring it entirely is not. It rarely shows up as a line item, which is exactly why it slips.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Explain the delay in the interface rather than hiding it. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.

How to tell if yours is fine

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

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.