Strategies to Scale Database Writes

In the previous article, we saw how to scale reads by reducing the amount of work the database has to do for every query.

Writes have a different problem.

A write is not just “store this data”.
A write often means:

• Update indexes
• Maintain order
• Enforce constraints
• Check relationships
• Modify multiple structures

As write traffic increases, the database becomes write-bound because every write forces the system to do a lot of organizational work.

So the goal of scaling writes is simple:

Make each write as lightweight as possible.

The Core Idea Behind Scaling Writes

A write becomes slow when the database has to:

• Update many indexes
• Maintain strict structure
• Perform synchronous checks
• Touch multiple data locations

So the strategy is:

Reduce how much work happens at the moment of the write.

Either:

• Postpone the work
• Distribute the work
• Simplify the work

Every technique below follows this idea.

1. Sharding (Horizontal Partitioning)

Instead of one database handling all writes, split data across multiple shards.

Each shard handles a portion of the data and the write load.

Why this works (theoretical view):

If one machine handles W writes/sec, N shards can handle roughly N × W writes/sec.

Writes are distributed instead of competing for the same resources.

2. Batch Writes

Instead of writing records one by one, group many writes together.

Databases and disks are much more efficient when handling larger sequential operations.

Why this works:

You reduce overhead per write and turn many small random operations into fewer sequential ones.

3. Asynchronous Writes

Instead of making the client wait until the data is fully written and indexed, acknowledge the write early and process the heavy work later.

Why this works:

User-perceived latency decreases, and the database can organize work more efficiently in the background.

4. Write-Ahead Logging (WAL)

Before modifying actual tables, the database writes the change to a log.

Logs are append-only and extremely fast to write.

Why this works:

The database first performs the cheapest possible write (append), and organizes data later.

5. LSM-Based Engines

LSM trees (used in Cassandra, RocksDB, LevelDB) write data to memory first and periodically flush sorted data to disk.

Why this works:

Writes are fast now, and sorting/organization happens later through compaction.

The work is deferred.

6. Idempotent Writes

Design writes so repeating the same write does not cause issues.

This allows retries, batching, and asynchronous processing without complex checks.

Why this works:

The database avoids extra read checks before writing.

7. Reduced Indexing

Every index slows down writes.

Limiting indexes to only what is necessary reduces write overhead.

Why this works:

Fewer structures to maintain means less work per write.

The Pattern Behind All These Techniques

All these strategies follow a common principle:

Make writes cheaper by reducing immediate organization work.

You either:

• Distribute the load
• Delay the work
• Simplify the structure
• Turn random writes into sequential ones

Final Thought

Scaling writes is not about making the database faster.
It is about making each write lighter.

You achieve this by:

• Postponing structure
• Distributing load
• Writing sequentially
• Avoiding unnecessary work