"Interview. In a multiplayer design tool, two users move the same object at the same moment. Wall-clock timestamps disagree because their machines' clocks differ by 400 ms. How do you decide what the document should show, and what would you say to an engineer who proposes using timestamps?" What is a strong answer?

The core point to make first

Wall-clock time cannot order distributed events. Clocks drift, are corrected by NTP in jumps that can move time backwards, and differ between machines by amounts far exceeding the interval you are trying to order. Using them means the result depends on whose laptop was more wrong, which is neither correct nor reproducible — and worse, it is usually fine, so it fails in production rather than in testing.

What to use instead

Logical ordering. Each client maintains a counter incremented on every operation and advanced to max(local, received) + 1 when it receives a remote operation. This produces a Lamport clock, which captures causality: if A happened before B and B knows it, B's counter is higher.

Ties — genuinely concurrent operations — are broken deterministically, typically by client identifier. The tie-break is arbitrary, and that is fine: what matters is that every replica breaks it the same way, so all replicas converge on the same document.

The insight that separates a strong candidate

For a design tool, exact ordering of concurrent edits mostly does not matter — convergence and intent preservation do. Two users moving the same object concurrently is a genuine conflict with no correct answer; the requirements are that all clients end up showing the same thing, the losing user sees their change reverted immediately and visibly rather than after a confusing delay, and nobody's unrelated work is lost.

That reframes the design: rather than ordering everything globally, model the document so that most concurrent operations do not conflict at all. Operations on distinct objects and distinct properties commute. Only same-object same-property operations need a tie-break, and those are rare.

The properties to state explicitly

• Per-object last-writer-wins with logical clocks for simple properties like position, where a deterministic winner is acceptable.
• CRDT structures for text, where last-writer-wins would destroy concurrent typing.
• Server as sequencer — many production systems route operations through a server that assigns an authoritative order. This sidesteps the hardest merge problems and is a legitimate engineering choice when clients are usually online. State the trade: it costs a round trip and requires the server to be reachable, in exchange for a much simpler client and easier debugging.

What to say to the engineer proposing timestamps

Not "that is wrong" but: "What happens when one user's clock is 400 ms ahead? Their later edit wins over the other user's earlier one, and the result depends on machine configuration rather than user action. Also, NTP can step time backwards, so a single client can produce two operations whose timestamps are out of order with respect to its own actions. We need something monotonic and causal — and if we want human time for display or audit, we can carry it as a separate field that nothing orders by."

That last clause matters: the answer is not to remove timestamps, but to stop them from carrying a guarantee they cannot provide.