Scaling Reads medium
A user updates their profile photo. They immediately refresh the page but still see the old photo. This happens because the read went to a Replica that hasn't synced yet. What strategy solves this specific UX problem?
- A Pinning: Route reads for a specific user to the Primary for a short duration after they perform a write.
- B Disable all Replicas.
- C Increase the TTL of the cache.
- D Use a faster internet connection.
Answer: A. Pinning: Route reads for a specific user to the Primary for a short duration after they perform a write.
This guarantees 'Read-Your-Writes' consistency. The user sees their own changes instantly (via Primary), while other users might see the old photo for a few milliseconds (via Replicas), which is acceptable.
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?