Scaling Writes medium
To ensure durability, databases write changes to a 'Write-Ahead Log' (WAL) on disk *before* modifying the actual data files. Why?
- A To compress the data.
- B Appending to a log file is a fast sequential I/O operation. Randomly updating the main data pages is slow. The WAL ensures data is saved quickly and safe from crashes.
- C To prevent SQL injection.
- D To make backups easier.
Answer: B. Appending to a log file is a fast sequential I/O operation. Randomly updating the main data pages is slow. The WAL ensures data is saved quickly and safe from crashes.
Sequential writes are significantly faster than random writes on both HDD and SSD. By flushing the WAL first, the database guarantees the transaction is durable (A in ACID) without waiting for complex data structure updates.
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?