In the last lesson a small program showed what an event with state costs: for the time the event about a moved deadline was in transit, sales knew the old one. You have known the same phenomenon for longer. The Kladde's pipeline board lags behind writing, and since lesson 4.4.5 the page shows a note when changes are still pending. Whoever clicks “Won” and is redirected back to the board sometimes still sees the deal in the old stage.
This lesson gives the phenomenon a name and measures. You learn two statements that every discussion of distributed data reaches sooner or later, CAP and PACELC, and read them the way they are meant. You learn the consistency models from strong to eventual and a guarantee that counts for the most in everyday work: whoever has written something also sees it. Azure Cosmos DB serves as a tangible example because it offers five levels to choose from and says exactly what each one promises. At the end the Kladde sets for every data flow which consistency it needs, and the board shows a person their own step instead of asking them for patience.
Four earlier lessons carry this one. Lesson 4.4.5 built read models with a projector that reads from a remembered position, and showed how the interface indicates that a read model is lagging. Lesson 4.5.1 showed that a grain has at most one activation, lesson 4.5.3 how the ETag protects the stored state from a second writer. And lesson 4.6.1 established that a message arrives at least once.
Where there are copies, there is a choice
Consistency becomes a question as soon as the same information exists in more than one place. In the Kladde that is more often the case than you think:
| Copy | Source | How it comes about |
|---|---|---|
| Pipeline board and forecast | stream of deals | projector, once a second (lesson 4.4.5) |
| Follow-up reminder in sales | sent quote | event QuoteSent |
| Submission deadline in the quotes, if kept as a copy | tenders | event with state (lesson 4.11.3) |
| Office and role of a person | tenants and Entra ID | in the token until it is renewed |
| Tenders in the Kladde | TED | nightly import |
| a row on a readable replica of the database, if one is used | the writable replica | replication in the database |
Every row asks the same two questions: May someone who reads the copy see an older state than the source? And if so, how old may it be, and who notices? The answers differ from row to row, and that is exactly the point of this lesson: consistency is not a property of a system but a decision per data flow.