Scaling Writes medium
You decide to shard your 'Orders' database to scale writes. You choose `Order_Creation_Date` as the Shard Key. What is the major architectural risk of this choice?
- A It requires too much storage space.
- B It creates a 'Hot Partition' (Write Hotspot). All new orders naturally fall into the same shard (e.g., 'Today's Shard'), leaving older shards idle and failing to distribute write load.
- C Date fields cannot be indexed.
- D It prevents backing up the database.
Answer: B. It creates a 'Hot Partition' (Write Hotspot). All new orders naturally fall into the same shard (e.g., 'Today's Shard'), leaving older shards idle and failing to distribute write load.
Monotonically increasing keys (like Dates or Auto-Increment IDs) concentrate all recent writes onto the single 'End' shard. To scale writes effectively, you want to distribute them evenly across *all* shards simultaneously (e.g., by hashing UserID).
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?