Clinic Vector Clocks
The ER and Ward can update a chart while the network is slow. Give each event a two-part memory so the clinic can tell what happened before—and what happened independently.
🧠 Before we start
In the Firefly Hash Ring, stable labels kept routes predictable. Today, a vector clock gives every update a causality label. Each station counts its own events, shares its knowledge, and keeps the largest count from every station.
Timestamp two independent updates
Tap one event at each station. A local event increases only that station's own part of the clock.
🚑 ER Station
ER knows its own updates and any Ward news received.
🛏️ Ward Station
Ward keeps the same two labels in the same order.
Deliver news and merge knowledge
Send the ER update to Ward. Ward keeps the larger value for each station, then counts the new receive event.
Read causality from two clocks
If every count is no larger and at least one is smaller, that update happened before. Crossing counts mean concurrent work.
Case A
Case B
Protect a concurrent patient record
Two offline stations changed different fields. Their clocks cross, so neither version contains the other. Choose the safe conflict policy.
🌟 What you learned
- A vector clock stores one counter for every participant.
- A local event increments only the local counter.
- A received message merges component-by-component maximums, then ticks the receiver.
- One vector smaller than another reveals happened-before order.
- Crossing values reveal concurrent updates that cannot be safely ordered.
- Detecting concurrency helps software preserve conflicts instead of silently losing data.