One system can contain several versions of the present.
A warehouse says an item has shipped while the customer portal still says packed. One bank has accepted a transfer while another has not yet reflected settlement. A transport control system sees a train in one location while a passenger information display has not yet caught up. A teacher has updated a learner’s diagnosis while an old worksheet still assumes the previous level.
The problem is state synchronisation: how separate parts of a system keep sufficiently compatible views of what is true now.
This is the natural next layer after state machines. A single component can know its own state. A distributed system must also decide how that knowledge travels.
Synchronisation Is Not the Same as Identical Copies
Perfectly identical state everywhere, at every instant, is often impossible or too expensive.
Messages take time. Networks fail. sensors update at intervals. Human organisations process records asynchronously. Two parts can therefore be briefly different without the system being broken.
The real question is: how different may they be, for how long, before a decision becomes unsafe or misleading?
Three Things Create State
- Observation: a sensor, person or subsystem reports something about the world.
- Event: something happens that should change the state.
- Record: the system stores a representation of that state so another component can use it later.
Synchronisation problems appear when these three move at different speeds.
The physical parcel has left. The scan event exists. The customer-facing record has not yet updated. Which state is “true”? Each layer is telling the truth about a different point in the chain.
Freshness Is Part of Meaning
A state without a time context can be dangerously incomplete.
“Inventory: 12” may have been true one second ago, one hour ago or yesterday. “Road clear” matters differently before and after an incident. “Student mastered fractions” is a stronger claim if it survived delayed retrieval than if it came from immediate guided practice.
Freshness is therefore not a technical footnote. It determines whether the state is still usable for the decision being made.
Clocks Help, but Clocks Are Not Enough
Time stamps help establish order, but distributed systems also face clock mismatch, delayed messages and events that are observed in different places.
Sometimes causal order matters more than wall-clock order. The important fact is that payment authorisation occurred before settlement, or that the door-close proof existed before movement authority was used.
A mature system therefore preserves enough sequence information to reconstruct what happened, not merely when each database wrote it down.
Push, Pull and Event Streams
Systems synchronise state in several broad ways.
- Push: the source sends updates when something changes.
- Pull: the receiver periodically asks for the current state.
- Event stream: changes are recorded as an ordered history that consumers process.
- Shared authoritative store: several components read from one state owner.
Each has trade-offs. Push can be fast but messages can be lost. Pull is simple but can be stale between checks. Event streams preserve history but require careful replay and ordering. Shared stores simplify authority but can become bottlenecks or single points of failure.
Authoritative State Matters
When two components disagree, one question becomes urgent: which source owns the truth for this field?
The shipping system may own physical dispatch. The payment ledger may own settlement. The school’s official record may own enrolment status. A local cache can be fast without being authoritative.
Without ownership, disagreement becomes argument rather than repair.
Synchronisation Can Be Strong or Eventual
Some decisions require near-immediate agreement. Others can tolerate temporary divergence.
A safety interlock cannot casually rely on eventual agreement about whether a door is open. A public catalogue may tolerate a few seconds of delay before a new record appears.
The required strength depends on consequence, reversibility and how much damage a stale decision can create.
Worked Example: Inventory
An online shop shows one unit remaining. Two customers buy almost simultaneously.
If the storefronts rely on stale copies of inventory, both may believe the item is available. The physical stock supports only one order.
The system now needs reservation logic, an authoritative inventory state or another mechanism to prevent a local view from making a promise the global system cannot keep.
Worked Example: Learning Records
A learner’s state can also become fragmented. One teacher sees improvement, an old test score still signals weakness, a parent sees homework success and the learner feels uncertain.
These are not necessarily contradictory. They may be observations from different times, tasks and levels of support.
Synchronising human learning therefore requires richer state than one number. We need provenance: what was demonstrated, under what conditions, when, and with how much independence.
What Happens When Synchronisation Fails?
- duplicate action;
- missed action;
- wrong sequencing;
- overselling or overbooking;
- unsafe permission;
- conflicting instructions;
- false alarms;
- users losing trust because two official interfaces disagree.
These are not just data problems. They become operational problems at the receiver.
Test Synchronisation by Creating Delay
A useful stress test is to imagine that one update arrives late.
- Choose a state-changing event.
- Delay delivery to one component.
- Ask what decisions that component can make while stale.
- Identify whether those decisions are reversible.
- Define the maximum tolerable lag.
- Define how the stale component detects that it is behind.
This exposes where synchronisation is a convenience and where it is a safety or integrity requirement.
The Civilisation Layer
Modern civilisation is a vast synchronisation project. Registries, financial ledgers, transport control, medical records, identity systems, inventories, public notices and institutional decisions all depend on separate actors sharing enough current state to coordinate.
Perfect simultaneity is not required. Reliable agreement at the decision boundary is.
State synchronisation works when every important decision sees a version of reality fresh and authoritative enough for the consequence it is about to create.
Continue through How Cross-System Handoffs Work, How Coordination Works and the master How X Works hub. The next problem is what happens when small differences do not disappear but accumulate: state drift.