Scaling Writes easy
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?
- A The database will run out of space.
- B It uses too much CPU.
- C Data Loss: If the database is down or the request fails, the application will never know, and the user thinks the action succeeded.
- D It is too slow.
Answer: C. Data Loss: If the database is down or the request fails, the application will never know, and the user thinks the action succeeded.
Waiting for an ACK (Acknowledgement) confirms durability. Skipping the wait improves latency (speed) but sacrifices reliability.
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?
- 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?
- When measuring how well your system handles writes, which metric is most important?