Practice the vocabulary of tolerating drift between independent clocks in a distributed system.
0 / 5 completed
1 / 5
At standup, a dev mentions the difference between a system clock's reported time and true time, or between two different nodes' clocks, which accumulates as drift across a distributed system. What is this difference called?
Clock skew is the difference between a system clock's reported time and true time, or between two different nodes' clocks, which accumulates as drift across a distributed system even between periodic synchronizations. Assuming a perfectly synchronized clock shared identically by every node ignores the physical reality that independent hardware clocks always drift somewhat. This skew is what makes comparing raw timestamps across two different nodes inherently risky without accounting for it.
2 / 5
During a design review, the team wants every node's clock periodically synchronized against a reference time source to narrow, though not fully eliminate, the skew between them. Which capability supports this?
NTP synchronization periodically aligns every node's clock against a reference time source, narrowing, though not fully eliminating, the skew that naturally accumulates between independent clocks. Leaving every node's clock entirely unsynchronized lets that skew grow much larger and more unpredictable over time. This periodic synchronization is a standard practice for keeping clock skew across a distributed system's nodes within a bounded, manageable range.
3 / 5
In a code review, a dev notices a protocol waits out a bounded uncertainty window before acting on a timestamp comparison, explicitly tolerating a known amount of possible clock skew rather than trusting an exact comparison. What does this represent?
Tolerating clock skew through a bounded uncertainty window has a protocol deliberately wait out a known, bounded amount of time before acting on a timestamp comparison, explicitly accounting for the possibility that two nodes' clocks aren't perfectly aligned. Acting immediately on an exact comparison assumes a precision between nodes that physical clocks can't actually guarantee. This bounded-uncertainty approach is what lets a distributed protocol remain correct even in the presence of a realistic, expected amount of clock skew.
4 / 5
An incident report shows two nodes with unsynchronized clocks disagreed on the ordering of two near-simultaneous events because the system compared raw timestamps directly without accounting for any clock skew between them. What practice would prevent this?
Designing the protocol to tolerate a bounded amount of clock skew, such as by waiting out an uncertainty window before acting on a timestamp comparison, prevents exactly the kind of disagreement this incident describes. Comparing raw timestamps directly with no accounting for skew assumes a precision between two independent nodes that real hardware clocks can't guarantee. This tolerance is a necessary design consideration for any protocol that relies on comparing timestamps from different nodes.
5 / 5
During a PR review, a teammate asks why the team designs a protocol to tolerate clock skew rather than assuming every node's clock is perfectly synchronized. What is the reasoning?
Physical clocks always drift somewhat even with periodic NTP synchronization, since synchronization narrows but never fully eliminates the skew between two independent nodes. A robust distributed protocol has to account for that bounded skew rather than trusting an exact timestamp comparison to always be correct. The tradeoff is the added complexity and occasional extra latency of waiting out an uncertainty window before acting on a timestamp-based decision.