Eventual consistency for small teams

The gap between knowing this and actually doing it is where most teams lose ground. Most advice about eventual consistency assumes a team that does not exist at your size. Here is the version that does not.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to keep

Users notice inconsistency long before your monitoring does. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Getting it slightly wrong is survivable. Ignoring it entirely is not.

Where to start

Explain the delay in the interface rather than hiding it. There is a version of this that is over-engineered, and it is worth avoiding. The version that survives contact with a real deadline is the simple one.

In practice

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
• 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

Most of the value here comes from doing the first two things, not all of them.