0
0
HLDsystem_design~10 mins

Write-through and write-back caching in HLD - Scalability & System Analysis

Choose your learning style9 modes available
Scalability Analysis - Write-through and write-back caching
Growth Table: Write-through vs Write-back Caching
Users / RequestsWrite-through CachingWrite-back Caching
100 usersCache updates on every write; low latency; DB load manageableCache holds writes; DB updated less frequently; risk of data loss low
10,000 usersDB write load increases linearly; cache write latency impacts user experienceCache write buffer grows; risk of stale data if cache fails; better DB load
1 million usersDB becomes bottleneck due to many writes; write latency affects throughputCache memory pressure high; complex eviction; risk of data loss higher; DB load manageable
100 million usersDB write capacity exceeded; system slows down; scaling DB costlyCache cluster needed; data consistency challenges; complex recovery; better DB scaling
First Bottleneck

For write-through caching, the database write throughput is the first bottleneck because every write must be immediately persisted to the database, increasing DB load linearly with traffic.

For write-back caching, the cache memory and eviction policy become bottlenecks as writes accumulate in cache before flushing, risking data loss and stale data if cache fails.

Scaling Solutions
  • Write-through: Use database write replicas to distribute read load; implement write batching if possible; add write caches with fast persistence layers (e.g., SSDs); horizontally scale DB with sharding.
  • Write-back: Increase cache cluster size; use distributed cache with persistence (e.g., Redis with AOF); implement reliable write-back flush policies; use write-ahead logs to prevent data loss.
  • For both: Use CDN for static content to reduce load; apply backpressure and rate limiting to control write bursts.
Back-of-Envelope Cost Analysis

Assuming 10,000 writes per second at 10KB each:

  • Write-through: 10,000 DB writes/sec -> DB must handle 10K QPS write load (near upper limit for single instance)
  • Write-back: Cache handles 10K writes/sec in memory; DB writes batched to 1,000/sec -> DB load reduced by 10x
  • Storage: 10KB * 10,000 writes/sec = ~100MB/sec write data; 8.6TB/day
  • Network: 1 Gbps link ~125MB/sec; write-through may saturate network; write-back reduces DB network usage
Interview Tip

Start by explaining the difference between write-through and write-back caching simply. Then discuss how each affects database load and data consistency. Identify the bottleneck for each approach and propose scaling solutions accordingly. Use real numbers to show understanding of system limits.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS writes. What do you do first?

Answer: Implement write-back caching to buffer writes in cache and batch them to the database, reducing DB write load. Also consider sharding or adding write replicas to scale DB horizontally.

Key Result
Write-through caching hits database write throughput limits first, while write-back caching shifts bottleneck to cache memory and data consistency. Scaling requires balancing DB load and cache reliability.