Scaling Writes

Overview

Some systems write far more than most: metrics and logs, sensor readings, clicks and likes, chat messages, payments at a sale. When one database can no longer keep up with the writes, reads-side tricks do not help. A cache can answer a read without the database, but every write has to reach the place where the data really lives. Read replicas do not help either: each one has to apply every write too.

Scaling writes means lowering the cost of each write, smoothing when writes arrive, and spreading them over more machines. The main tools are batching (many rows per round trip and per disk flush), buffering in a durable log such as Kafka, sharding (splitting data so each machine takes part of the writes), storage engines built for writes such as LSM trees, and rules for accepting writes in more than one region.

Each tool gives something up. Batching adds latency. A buffer means the database is behind. Sharding makes queries across shards expensive. Accepting writes in two places means two writes can conflict. A strong answer picks tools per data type and says what each costs.

What you will be able to do

• Explain why writes are harder to scale than reads.
• Use batching, group commit and bulk loading, and estimate their effect.
• Put a durable queue in front of a database without losing writes.
• Spread hot keys and counters, and explain write amplification in B-trees and LSM trees.
• Choose how to accept writes in several regions and how conflicts are resolved.

Key concepts

• Why writes are harder
• Batching and group commit
• Queue as a write buffer
• Sharding
• Hot keys and counters
• LSM trees
• Write amplification
• Durability vs latency
• Multi-region writes
• CRDTs

Interview questions

• Your database cannot keep up with writes. What do you do, in order?
• Why doesn't adding read replicas or a cache help with write load?
• How does batching raise write throughput, and what does it cost?
• Design the ingestion path for millions of sensor readings per second.
• What is write amplification, and where does it come from?
• How do you put a queue in front of a database without losing or duplicating data?
• How would you handle a counter that receives millions of increments, such as views on a viral video?
• Users in Europe and the US both edit data. How do you handle writes?

More System Design topics

• Redundancy and Replication
• REST vs RPC vs GraphQL
• Returns and Refund Management System
• RPO & RTO
• Saga Pattern for Distributed Transactions
• Scaling Reads
• Search Ranking System
• Search System Design
• Security
• Segmented Log
• Semantic Cache for LLM Responses
• Sentiment Analysis System