Scaling Reads hard
You use Materialized Views for fast reads. You need real-time freshness, so you trigger a refresh on every write. What is the downside?
- A Read speed decreases.
- B Write Amplification. A single user write now triggers expensive view re-calculations, effectively moving the Read cost to the Write path and potentially locking tables.
- C Data becomes stale.
- D Storage cost increases.
Answer: B. Write Amplification. A single user write now triggers expensive view re-calculations, effectively moving the Read cost to the Write path and potentially locking tables.
This defeats the purpose of the view if writes are frequent. It couples the write latency to the complexity of the read query. Usually, 'Incremental Refresh' or 'Batch Refresh' is preferred.
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?