Scaling Writes hard
How does Google Spanner utilize 'TrueTime' (Atomic Clocks + GPS) to achieve External Consistency (Linearizability) across global writes?
- A It synchronizes clocks perfectly to 0ms.
- B Commit Wait: A transaction waits out the clock uncertainty interval (epsilon) before committing, ensuring that if T2 starts after T1 finishes, T2 is guaranteed to see a timestamp greater than T1.
- C It uses NTP to speed up writes.
- D It ignores clock skew and relies on logical clocks.
Answer: B. Commit Wait: A transaction waits out the clock uncertainty interval (epsilon) before committing, ensuring that if T2 starts after T1 finishes, T2 is guaranteed to see a timestamp greater than T1.
Spanner accepts that clocks have error ranges. By waiting for the *maximum possible error* duration (usually <10ms) before reporting 'Success', it guarantees that timestamps effectively reflect real-world time order.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What does the 'Atomicity' property in a database transaction guarantee regarding writes?
- Your database is struggling with write traffic. You decide to 'Scale Up' (Vertical Scaling) by buying a bigger server. What is the eventual hard limit of this strategy?
- A developer sets up a 'Fire-and-Forget' write pattern (sending data without waiting for a database confirmation) to speed up the app. What is the major risk?
- Why is inserting 1,000 rows in a single 'Batch' query faster than executing 1,000 separate `INSERT` queries?
- In the Raft consensus algorithm, what mechanism prevents a 'Split Vote' (where no leader gets a majority) from stalling the cluster indefinitely?
- Your 'Logs' table has 10 billion rows and writes are getting slow. You barely access logs older than 1 year. What is the simplest strategy to improve performance?