Scaling Reads hard
You use 'Last-Write-Wins' (LWW) to resolve conflicts between replicas. Why is this dangerous for data integrity in a distributed system?
- A It is slow.
- B Physical clocks are never perfectly synchronized (Clock Skew). A write from a 'lagging' server might unintentionally overwrite a newer write from a 'fast' server simply because its clock is ahead.
- C LWW requires manual intervention.
- D It uses too much CPU.
Answer: B. Physical clocks are never perfectly synchronized (Clock Skew). A write from a 'lagging' server might unintentionally overwrite a newer write from a 'fast' server simply because its clock is ahead.
Time is unreliable in distributed systems. Relying on wall-clock time for conflict resolution inevitably leads to silent data loss. Vector Clocks are the robust alternative.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a caching system, what is a 'Cache Miss'?
- Why is `SELECT * FROM Users` generally discouraged in high-performance applications compared to `SELECT name, email FROM Users`?
- You have users all over the world downloading large images from your server in New York. Users in Australia complain it is slow. What solves this?
- What is the main downside of reading from a Read Replica instead of the Primary database?
- You have maximized the RAM on your single database server, but it's still too slow. You decide to add 10 more servers to share the load. What is this called?
- You have 5 Read Replicas. How does the application know which one to ask for data?