Scaling Writes hard
When load testing a write-heavy system, why might your latency charts look good (e.g., 50ms) while users report the system is stalled?
- A Coordinated Omission: The load generator waits for a response before sending the next request. If the server stalls for 10s, the generator sends nothing, failing to record the 10s of queuing latency that real users would experience.
- B The users are wrong.
- C The charts average the data.
- D Network jitter.
Answer: A. Coordinated Omission: The load generator waits for a response before sending the next request. If the server stalls for 10s, the generator sends nothing, failing to record the 10s of queuing latency that real users would experience.
Bad testing tools accidentally coordinate with the system under test. If the system slows down, the test slows down, masking the backlog. Correct testing tools send requests asynchronously at a fixed rate.
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?