Scaling Writes medium
According to the CAP Theorem, if you choose an 'AP' (Available + Partition Tolerant) database like Cassandra for writes, what trade-off must you accept?
- A The database will go offline during network failures.
- B Writes will be rejected if quorum is not met.
- C Eventual Consistency. The database accepts writes on any node immediately, but it might take time for all nodes to agree on the data.
- D Writes are slower.
Answer: C. Eventual Consistency. The database accepts writes on any node immediately, but it might take time for all nodes to agree on the data.
AP systems prioritize 'Always Writable'. Even if the network is split, you can write to the minority side. The trade-off is that reads might return conflicting or stale data until the partition heals.
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?