How Can Two Offline Teams Keep Both Inspection Counts?

Each maintenance team finishes inspections while disconnected. When their tablets reconnect, replacing one total with the other loses work. Adding the two totals can also count shared history twice.

We need to preserve enough information to tell which contribution belongs to which writer. A grow-only counter gives each replica its own component. That small change lets us derive a repeatable merge instead of guessing which total to trust.

Merge each component with maximum, then compute the total from the merged component map.

{
  "components": {
    "east": 3,
    "west": 4
  },
  "total": 7
}

A last-write-wins policy uses an ordering, often involving a timestamp and a tie-breaker, to choose one value. It can be useful for a replaceable preference, but it can discard an independent update to an inspection total. Wall clocks can also disagree, so a later timestamp does not necessarily identify the later real-world action.

Different fields may need different treatment. A technician’s note should not automatically be merged with the same rule as a set of completed inspection IDs or a stock reservation.

Convergence describes agreement after merging. It does not establish that the chosen value preserves the application’s intent.

The counter state is a dictionary from replica ID to its nonnegative count. East increments only east’s component; west increments only west’s component. A replica may copy the whole map, but it must not independently invent increments for another owner.

Counts only increase. A replica that loses its local state cannot safely reset its old component to zero and continue under the same identity. Recovery must restore that state or introduce a new unique writer identity under a documented policy.

The ownership and no-reset assumptions make maximum a meaningful merge.

For each owner, the larger observed count includes at least the progress represented by the smaller one. Retain that maximum. A missing component represents zero progress in that snapshot. After merging all owners, sum their retained contributions.

Use a dictionary for named components rather than a list whose positions silently depend on the order writers joined. Sorting the names only gives a repeatable display; it does not change the mathematical state.

merged[owner] = max(left.get(owner, 0), right.get(owner, 0))
total = sum(merged.values())

This formula performs a merge of states, not a replay of increment commands.

earlier = 2
later = 5
merged = max(earlier, later)
replayed = max(merged, earlier)
print(merged)
print(replayed)

5
5

Merging a state with itself leaves it unchanged: idempotence prevents duplicate snapshots from inflating the result. Swapping the two inputs gives the same state: commutativity removes dependence on arrival order. Grouping successive merges differently also gives the same state: associativity allows intermediate replicas to combine updates.

Those properties help when valid states eventually reach the replicas that need them. They do not deliver messages, authenticate writers or guarantee that every offline device will reconnect. The application still has to satisfy the communication and identity assumptions.

The challenge tests these properties on concrete component maps instead of treating one displayed total as sufficient evidence.

A grow-only counter cannot represent removing an inspection. One extension keeps separately owned positive and negative components and subtracts their totals, with its own rules. Sets with removal also need information about which additions were observed; deleting a value from a plain union can be undone by a delayed copy.

Do not implement removal by decreasing a component in this counter. A remote replica holding the previous larger value would restore it at the next maximum merge.

A new operation can require a new data type and a new proof of its merge behaviour.

Two disconnected teams can each decrement a local available-stock estimate and later agree on a negative total. The merge can be internally consistent while violating the business invariant that stock must never be oversold.

Coordination, preallocated spending rights or another specialised design is needed when the invariant requires it. Our earlier conditional write intentionally took a different approach for a single authoritative stock item.

Choose availability and merging only where the permitted outcomes match the maintenance task.

A document can contain two incompatible repair decisions that no automatic rule should erase. Retain the relevant versions, actors and source evidence, then route the conflict for reconciliation. The resolver’s decision becomes a new recorded action.

Choose a policy before an outage produces competing writes. A deterministic arbitrary winner makes failures reproducible, but it does not make a lost repair note acceptable.

Botie’s changed counter case tests repeated and older observations. It does not claim a universal conflict resolver.