Strategies to Handle Both Reads and Writes at Scale

In the previous two articles, we saw something important:

• To scale reads, we reduce the work the database does per query. [LINK]
• To scale writes, we reduce the work the database does per insert. [LINK]

But what happens when a system has both heavy reads and heavy writes?

This is where most real-world systems struggle.

Because we already know a fundamental truth:

Reads and writes want opposite storage designs.

So how do modern large-scale systems handle both?

They don’t remove the tradeoff.

They separate, distribute, and reorganize where the work happens.

This article explains the architectural patterns that allow systems to scale reads and writes together by moving beyond a single database design.

The Core Idea

You cannot make one storage layout perfect for both reads and writes.

So the strategy becomes:

Don’t rely on a single layout.

Instead:

• Split data
• Split workloads
• Split responsibilities
• Let different parts of the system optimize for different things

1. Sharded + Replicated Architecture

When your system has both heavy reads and heavy writes, a single database server will quickly become a bottleneck.

To solve this, we use sharding and replication together.

Step 1: Sharding (Horizontal Partitioning)

• The data is split into multiple shards, usually by some key (user ID, region, order ID, etc.).
• Each shard is stored on a different machine.
• Write advantage: Each write only touches one shard, not the entire dataset.
• This spreads the write load across multiple machines, so no single server gets overwhelmed.

Example:
If you have 1 million users and 4 shards:

• Users 1–250k → Shard 1
• Users 250k–500k → Shard 2
• Users 500k–750k → Shard 3
• Users 750k–1M → Shard 4

Each shard only handles writes for its portion of users.

Step 2: Replication

• Each shard is copied to multiple machines (replicas).
• Read advantage: Read queries can be served from any replica.
• This spreads read traffic and avoids overloading a single machine.

Example:
If Shard 1 has 3 replicas:

• Replica A serves some reads
• Replica B serves other reads
• Replica C can be used as backup or for heavy reporting

Why this works:

1. Sharding spreads writes horizontally — multiple servers handle write operations in parallel.
2. Replication spreads reads horizontally — multiple replicas can serve queries at the same time.
3. You are effectively scaling both dimensions: writes AND reads, without forcing one server to do everything.

2. CQRS (Command Query Responsibility Segregation)

CQRS is an architectural pattern that separates how you handle writes (commands) from how you handle reads (queries).

Write Model: This part of the system handles all changes to the data — inserts, updates, deletes.

• Optimized for fast writes.
• Often uses minimal indexes, append-only logs, or other write-friendly structures.

Read Model: This part handles all queries and reports.

• Optimized for fast reads.
• Often precomputes joins, stores denormalized data, maintains indexes, or uses caches.

Key idea: Instead of forcing a single database to be good at both reading and writing (which is fundamentally conflicting), CQRS creates two separate “views” of the data:

• One for writing efficiently
• One for reading efficiently

How it works in practice:

• When a write happens, it updates the write model.
• A background process propagates changes to the read model (sometimes immediately, sometimes eventually).
• Queries read from the read model, not the write model.

Why this works:

• You remove the tension between read and write optimization.
• Each model can use storage structures that are best suited for its purpose.
• Writes are not slowed down by read-specific indexes or precomputed views.
• Reads are not slowed down by write-heavy append operations or log processing.

3. Distributed Databases

When your system grows beyond the capacity of a single server, a distributed database becomes necessary.

A distributed database spreads data across multiple nodes and automatically manages:

• Replication — creating copies of data for fault tolerance and read scaling
• Partitioning (sharding) — dividing data so that no single node holds everything
• Routing — sending queries to the correct node that owns the data

Why this works:

• Each read or write is sent to the node that owns the relevant data.
• Nodes handle requests independently, reducing contention and avoiding a single bottleneck.
• Reads and writes are naturally balanced across the cluster because data is distributed.
• Fault tolerance and redundancy come for free — if one node fails, others can serve requests.

4. Consistent Hashing

When a system has many nodes, a challenge arises:

• How do you decide which node stores which data?
• How do you handle nodes being added or removed without moving all the data?

Consistent hashing solves this elegantly.

How it works:

• Every node and every piece of data is assigned a position on a hash ring.
• Each piece of data is stored on the closest node clockwise on the ring.
• If a node is added or removed, only a small portion of the data needs to move.

Why this works:

• Data is automatically evenly distributed across nodes.
• No single node becomes a hotspot, preventing overload.
• Reads and writes are naturally balanced because each node gets roughly the same portion of data.
• The system doesn’t require a central coordinator to track everything — each node can figure out where data belongs.

5. Partition Pruning

As tables grow larger, scanning the entire dataset for every query becomes very expensive.
Partitioning is a technique to split a large table into smaller, manageable pieces based on some key, like:

• Time (e.g., logs by day or month)
• Region (e.g., users by country)
• Category (e.g., orders by product type)

Each piece is called a partition.

How it works:

• Queries include a filter on the partition key (e.g., WHERE date = ‘2026-01-31’).
• The database can skip irrelevant partitions entirely, only scanning the data that matters.
• Writes are directed to the correct partition, leaving other partitions untouched.

Why this works:

• Reads become faster because the database touches less data.
• Writes become lighter because only a single partition is modified.
• Both operations are optimized without changing the underlying storage.

6. Event Sourcing

In traditional databases, we store the current state of data — for example, a user’s account balance.

Event sourcing takes a different approach:

• Instead of storing the current state, the system stores every change as an event in an append-only log.
• Examples of events: “User deposited $50,” “User withdrew $20,” “User updated email.”
• The current state can always be reconstructed by replaying these events.

How it works:

• Writes are simple appends to the event log — no need to update multiple tables or maintain complex indexes immediately.
• Read models are built separately from the event log. These read models are optimized for queries, often denormalized or precomputed.

Why this works:

• Writes are extremely fast because the database only needs to append events sequentially.
• Reads are fast because the read models are built specifically for query patterns.
• The system separates the conflicting goals of writes and reads into different workflows, avoiding the tradeoff inside a single structure.

7. Data Locality (Geo-Sharding)

When applications serve users across the globe, a single central database can create network delays:

• A user in India reading data from a database in the US experiences high latency.
• Every write has to travel long distances, slowing down the system and creating bottlenecks.

Geo-sharding solves this by storing data close to where it is most frequently accessed.

How it works:

• Users in each region are assigned to a nearby shard or node.
• Reads and writes for that region go to the local node instead of a central server far away.
• Data can be synchronized between regions as needed, often asynchronously.

Why this works:

• Reads are faster because data is local and avoids long network hops.
• Writes are faster because the local node can handle updates without waiting for a distant central server.
• Central bottlenecks are reduced because traffic is distributed geographically.

Intuition:

Imagine a global chain of post offices:

• People in London use the London office.
• People in Tokyo use the Tokyo office.
• Packages don’t have to travel across the world for every transaction.

This reduces delays and spreads the workload evenly.

The Pattern Behind All These Techniques

All these strategies follow a single principle:

If one database design cannot serve both reads and writes efficiently, use multiple designs working together.

You scale reads and writes together by:

• Distributing data
• Separating responsibilities
• Isolating workloads
• Reorganizing data continuously

Final Thought

You cannot defeat the read-write tradeoff inside a single storage layout.

But you can design a system where different parts handle different responsibilities.

Modern large-scale systems do not rely on one database to do everything.