Database Design • Read-Heavy vs Write-Heavy OptimizationEasy⏱️ ~2 min
What Makes a System Read Heavy or Write Heavy?
Workload shape determines fundamental architectural decisions. A system is read heavy when fetch operations outnumber mutations by a significant ratio, typically 10:1 or higher. A system is write heavy when it continuously ingests high volumes of mutations, often with bursty patterns. Most production systems are mixed, but the critical path for user experience dictates optimization bias.
Read heavy systems optimize for low latency, high throughput fetches with minimal origin database work per request. Meta's TAO social graph store handles read to write ratios of 100:1 or higher, serving 1 to 2 million operations per second from a single cache node with sub millisecond latency. Netflix delivers over 90% of bytes from edge caches, reducing origin load dramatically while achieving sub 10ms Round Trip Times (RTTs) to users.
Write heavy systems optimize for durable, scalable ingestion and smooth load distribution under constant mutation. LinkedIn's Kafka infrastructure transports trillions of messages daily with peak throughput reaching tens of millions of messages per second. The system decouples write intensive event streams from read optimized views, allowing asynchronous materialization without blocking producers.
The central trade off is where to invest complexity. Read optimization adds caching layers, replication, and precomputation at the cost of storage overhead and staleness risk. Write optimization adds buffering, sharding, and eventual consistency at the cost of more complex reconciliation and potential read after write delays.
💡 Key Takeaways
•Read to write ratio above 10:1 signals read heavy optimization: invest in caching, replication, and precomputation to achieve sub 50ms p95 latency
•Write heavy systems with sustained high ingest rates (100K+ writes/sec) require buffering, sharding, and eventual consistency to smooth bursty load
•Mixed workloads are common but critical path drives bias: Meta optimizes for read latency on social graph despite constant writes, Netflix optimizes edge delivery despite personalization writes
•Storage overhead trade off: read optimization can increase storage by 3x to 10x through denormalization and materialized views in exchange for faster queries
•Consistency trade off: write heavy systems accepting eventual consistency achieve 5x to 20x higher throughput compared to strongly consistent writes that block on replication
📌 Examples
Meta TAO serves 1-2 million ops/sec per cache node with sub millisecond latency, handling 100:1 read:write ratio across social graph with asynchronous replication
Netflix delivers over 90% of traffic from Open Connect edge caches at hundreds of Tbps globally, keeping origin load minimal with p95 UI loads under 20-50ms
LinkedIn Kafka handles tens of millions of messages per second at peak, decoupling write streams from read views with asynchronous consumers