How to Scale Reads and Writes
Quick answer: How to Scale Reads and Writes
How to Scale Reads and Writes is covered here as a practical system design article. Practical strategies for scaling read and write throughput — replicas, caching, sharding, async processing, and the CQRS pattern. Use it to turn a broad system design idea into an interview-ready checklist with practical examples and links to deeper topics.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
How to Scale Reads and Writes
Most applications start with a single database handling both reads and writes. This works until it does not. Understanding which bottleneck you are hitting — reads or writes — determines the right scaling strategy.
Scaling Reads
Read bottlenecks are the most common scaling problem. A typical web application has a 10:1 or even 100:1 read-to-write ratio. Three primary strategies address this.
Read Replicas
Create copies of your primary database that serve read queries. The primary handles writes and replicates changes to replicas asynchronously. This scales read throughput linearly: add more replicas, serve more reads.
Tradeoff: Replication lag means replicas may serve slightly stale data. For most applications (displaying profiles, listing products), this is acceptable. For operations that must read what was just written (e.g., showing a user their own post immediately after creating it), route those reads to the primary ("read-your-writes" consistency).
Caching
Place a cache (Redis, Memcached) between the application and the database. Cache frequently accessed data with a TTL (time-to-live). Cache hit ratios of 90%+ are common, meaning 90% of reads never reach the database.
Cache-aside pattern: Application checks cache first. On a miss, it queries the database, stores the result in cache, and returns it. On write, invalidate the cache entry.
Tradeoff: Stale data (cache may serve outdated values until TTL expires or explicit invalidation). Cache invalidation is one of the two hard problems in computer science. Thundering herd: when a popular cache entry expires, hundreds of concurrent requests hit the database simultaneously.
Denormalization
Store precomputed results or redundant copies of data to avoid expensive joins or aggregations at read time. For example, store a user's follower count directly on the user record rather than counting the followers table on every request.
Tradeoff: Write complexity increases (you must update the denormalized data whenever the source data changes) and storage increases, but reads become trivially fast.
Scaling Writes
Write bottlenecks are harder to solve because writes must (usually) go to a single authoritative location to maintain consistency.
Sharding (Horizontal Partitioning)
Split your data across multiple database instances based on a shard key (e.g., user_id modulo N). Each shard handles a fraction of the total write load. This scales write throughput linearly.
Tradeoff: Cross-shard queries become expensive or impossible. Choosing the wrong shard key leads to hotspots (one shard receiving disproportionate load). Re-sharding (changing the number of shards) is operationally painful. Consistent hashing can mitigate re-sharding cost.
Asynchronous Processing
Not all writes need to be processed synchronously. Place writes into a message queue (Kafka, SQS, RabbitMQ) and process them asynchronously. The API returns immediately after enqueuing, and workers process the writes at their own pace.
Tradeoff: The user does not see the result immediately (eventual consistency). Suitable for non-critical writes like analytics events, email sends, or feed updates. Not suitable for writes where the user needs immediate confirmation (e.g., payment processing).
Write-Behind Caching
Buffer writes in a fast store (Redis) and periodically flush them to the database in batches. This absorbs write spikes and reduces the number of database writes.
Tradeoff: Risk of data loss if the buffer fails before flushing. Use a WAL or persistent queue for durability.
CQRS: Command Query Responsibility Segregation
When read and write patterns diverge significantly, separate them into different models. The write model (commands) uses a normalized, write-optimized store. The read model (queries) uses a denormalized, read-optimized store (or cache, or search index). An event bus synchronizes the two.
Example: An e-commerce system writes orders to a normalized PostgreSQL database. A separate service consumes order events and materializes a denormalized view in Elasticsearch for the product search page.
Tradeoff: Increased complexity (two data models, eventual consistency between them, event infrastructure). Only justified when the read/write asymmetry is extreme or when read and write models have fundamentally different shapes.
Decision Guide
| Symptom | Strategy |
|---|---|
| Database CPU saturated by SELECT queries | Read replicas |
| Same queries executed repeatedly | Caching |
| Complex joins on every read | Denormalization |
| Write throughput limited by single node | Sharding |
| Non-critical writes causing backpressure | Async processing |
| Reads and writes have very different shapes | CQRS |
Summary
Scale reads with replicas, caching, and denormalization. Scale writes with sharding and async processing. When the asymmetry is extreme, consider CQRS. Always start with the simplest strategy that solves your bottleneck, and measure before adding complexity.
Original DosiBridge notes for How to Scale Reads and Writes
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study How to Scale Reads and Writes is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Practical Lesson: For How to Scale Reads and Writes, decide the practical lesson before choosing tools; otherwise the design looks clean but fails when how changes.
- Migration Story: For How to Scale Reads and Writes, decide the migration story before choosing tools; otherwise the design looks clean but fails when to changes.
- Production Symptom: For How to Scale Reads and Writes, decide the production symptom before choosing tools; otherwise the design looks clean but fails when scale changes.
- Decision Checklist: For How to Scale Reads and Writes, decide the decision checklist before choosing tools; otherwise the design looks clean but fails when reads changes.
- Rollback Plan: For How to Scale Reads and Writes, decide the rollback plan before choosing tools; otherwise the design looks clean but fails when and changes.
Production review question
If a team adopts How to Scale Reads and Writes, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track how-writes health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For How to Scale Reads and Writes, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.