Advanced

Model Answer

Not reliably. Physical clocks drift and NTP corrections can cause non-monotonic updates. Clock skew of tens of milliseconds is normal. For events within the skew window, timestamps do not establish ordering. Use Lamport clocks (logical clocks) if you need causal ordering: if A causally precedes B, then L(A) < L(B). For tracking concurrent events, use vector clocks. For a global total order close to real time, use Hybrid Logical Clocks (max of wall clock and received HLC) as CockroachDB does, or TrueTime as Google Spanner does.

Model Answer

A Lamport clock is a logical counter. Rule: on send, increment and attach. On receive, set to max(local, received) + 1. Guarantee: if A happens-before B, then L(A) < L(B). Does NOT guarantee the converse: if L(A) < L(B), A may or may not have happened before B (they might be concurrent). Lamport clocks establish a total order consistent with causality, but cannot distinguish concurrent events from causally ordered ones.

Model Answer

Options: (1) Vector clocks: each service maintains a vector of counters; causality is fully tracked but vectors are O(N) in size. (2) Hybrid Logical Clocks (HLC): each service tracks max(wallClock, lastSeenHLC). Clock values are bounded to wall time within the system's max clock skew. Events are ordered by HLC; concurrent events have indeterminate order. (3) Distributed tracing with causal metadata (propagate trace IDs and parent span IDs through RPC calls — this is what OpenTelemetry does). Option 2 is the practical choice for most systems; option 1 for systems requiring full causality tracking; option 3 for debugging.

Model Answer

TrueTime is Google's API for the current time, implemented with GPS receivers and atomic clocks in every datacenter. It returns an interval [earliest, latest] where the true current time is guaranteed to be. The uncertainty is typically 1-7ms. Spanner uses it for commit wait: after the leader decides a commit timestamp T, it waits until TrueTime.now().earliest > T before releasing the transaction. This ensures that any subsequent transaction starting anywhere will have a TrueTime range that begins after T, providing external consistency. No other production system has this — CockroachDB approximates it with bounded clock synchronization and conservative uncertainty estimates.

Model Answer

Root cause: physical timestamps from different machines are used to sort log entries, but the machines have clock skew. An event on a fast-clock machine at T may appear before an event on a slow-clock machine at T-5ms even though the slow-clock event causally preceded it. Fix: (1) Use logical timestamps (Lamport/vector clocks) instead of physical time for ordering events in logs. (2) Propagate a monotonic request ID through all service calls and sort by causal chain rather than time. (3) Use a centralized log aggregation system (e.g., Kafka) where producers attach their HLC timestamp, and the aggregator uses the highest received timestamp as a lower bound for ordering.