Applied · Module 4
Data, state and consistency
State hides everywhere.
Previously
Quality attributes and trade offs
latency and throughput are easy to measure.
This module
Data, state and consistency
State hides everywhere.
Next
Software Development and Architecture Intermediate practice test
Test recall and judgement against the governed stage question bank before you move on.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
A product shows prices from a cache.
What you will be able to do
- 1 Explain data, state and consistency in your own words and apply it to a realistic scenario.
- 2 Consistency is a decision. Choose where you need strong guarantees and where you can relax them.
- 3 Check the assumption "Consistency needs are known" and explain what changes if it is false.
- 4 Check the assumption "Failure is expected" and explain what changes if it is false.
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Inconsistent reads. Users see surprises when consistency is assumed but not enforced.
- State split across systems. When state is split without clear ownership, debugging becomes slow.
Main idea at a glance
State flow
Understand write truth, read projections, and staleness detection.
Stage 1
Write request
Client initiates a change to system state.
I think every write should be idempotent.
State hides everywhere. It lives in databases, caches, and message queues. consistency comes in two main flavours. eventual consistency is common in distributed systems.
Distributed systems are hard because the network is slow and things fail. You decide where you accept delay and where you need certainty.
Worked example. The “stale price” incident
Worked example. The “stale price” incident
A product shows prices from a cache. The database updated, but the cache did not invalidate. Customers see stale prices, the business loses money, and everyone blames “eventual consistency” like it is a curse.
Eventual consistency is not a bug, it is a design choice. The question is whether you designed user experience, monitoring, and recovery around that choice.
Common mistakes with state
State management mistakes to remove
State incidents usually happen in the gap between write truth and read experience.
-
No cache invalidation strategy
Define deterministic cache invalidation and monitor staleness as a first-class signal.
-
Assuming database truth is enough
If users read projections, monitor projection lag and read correctness directly.
-
No read/write incident split
Separate read-path and write-path triage so incidents are diagnosed quickly.
Verification. Can you reason about consistency under failure
Consistency verification under failure
Use this mini-runbook before releasing distributed data changes.
-
Map source of truth and read source
Document exactly where authoritative writes occur and where user reads are served.
-
Simulate bus lag and replay
Test delayed events and replay scenarios to confirm reconciliation behaviour.
-
Monitor staleness directly
Track freshness SLOs and mismatch counts, not only hard system errors.
CPD evidence (keep it real)
CPD evidence checklist
Keep your evidence concise and audit-ready.
-
What I studied
Architecture styles, integration patterns, quality trade-offs, and state consistency behaviour.
-
What I practised
One justified style choice, one failure-aware integration flow, and one consistency scenario write-up.
-
What changed in my practice
Example habit: I now check retries and idempotency before approving integration changes.
-
Evidence artefact
A one-page design note with trade-offs, verification checks, and rollback triggers.
Mental model
Data, state, and consistency
Consistency is a decision. Choose where you need strong guarantees and where you can relax them.
-
1
Write
-
2
State
-
3
Read
-
4
Consistency choice
Assumptions to keep in mind
- Consistency needs are known. If you do not know where consistency matters, you cannot design for it.
- Failure is expected. Distributed systems fail. Your design should state what happens then.
Failure modes to notice
- Inconsistent reads. Users see surprises when consistency is assumed but not enforced.
- State split across systems. When state is split without clear ownership, debugging becomes slow.
Key terms
- consistency
- How aligned different parts of the system are at the same time.
- eventual consistency
- A style where parts may disagree for a short time, but they line up if we wait.
Check yourself
Quick check. Data and state
0 of 7 opened
Where can state live
Databases, caches, and message queues.
What is eventual consistency
Parts may disagree briefly but align over time.
Scenario. The database updated but users still see old values. What is a likely cause
A stale cache or projection. The write path succeeded but the read path is serving an old copy because invalidation or refresh failed.
Why are distributed systems hard
Networks are slow and failures happen.
Why use caches
To speed up reads and reduce load.
What is the cost of strong consistency
Potentially higher latency and lower availability.
Why send events
To share state changes across services.
Artefact and reflection
Artefact
A one-page decision note with assumption, evidence, and chosen action
Reflection
Where in your work would explain data, state and consistency in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
Toggle where state lives and watch it drift or align.