DEV Community: Akbar Dizaji

Why One Writer Can Beat Hundreds of Threads

Akbar Dizaji — Mon, 03 Aug 2026 07:27:57 +0000

Single Writer Principle: Why Allowing Only a Single Writer to Do the Writing Can Speed Up Your Application

Every day, you are using this approach without even knowing it.

Forget about mutexes and fancy synchronization techniques for now. Let's ask ourselves a very basic question.

What if, instead of coordinating many writers writing in the same book, we allow just one writer to write there?

What would be its advantages? What would be its disadvantages?

This basic concept forms the basis of many efficient and scalable applications that you will learn about later in the chapter. It is known as the Single Writer Principle.

In the Case of Race Between Several Authors

Let’s picture an account that has 100 dollars.

Two commands almost simultaneously enter the system:

add 50
subtract 20

Both threads would probably read 100 as the initial amount, compute, and overwrite one another's calculation results.

Depending on circumstances, the final balance may not be correct.

Here we come across the typical race condition problem.

What is the very first solution that occurs?

Indeed! – use a lock.

That works.

But not for free, of course.

The Costs of Locking

Many software developers believe that a lock is just a tiny cost - a few nanoseconds.

In fact, the indirect costs may be significantly higher:

The threads wait for a lock.
Context switching is done by the OS.
CPU cores constantly invalidate cache lines of other cores (cache invalidation).
Deadlocks can happen more often.
The code gets really hard to understand and that's precisely what drives developers nuts.

As the number of threads increases, performance does not necessarily increase.

Quite often, it drops.

A More Sophisticated Approach - Keep Things Simple

Allow Only One Thread to Write

The Single Writer approach sounds pretty simple.

Instead of letting every thread to update the shared state directly (note how important the term state becomes here) all threads just push their updates into the queue.

And a single thread takes care of the queue processing requests one by one.

No matter what, there is always just one writer that changes the shared state at the time.

Since there is no concurrent writes:

No race conditions anymore.
Locks are usually redundant.
The code becomes way more understandable.

Why can a Single Thread be faster than Multiple Threads?

At first glance, it sounds strange.

How can a single thread be faster than multiple threads?

But everything is very simple.

If there is always a lock for which multiple threads are waiting, then all threads spend their time not working but competing among themselves for the right to take the lock.

On the other hand, a Single Writer does not wait for locks and does not coordinate with other writers while processing incoming requests.

CPU also gets:

Sequential access to memory
Improved Cache Locality
No Cache Line bouncing due to concurrent write operations

That's why, in a lot of highly performant systems, reduction of contention is more beneficial than increasing the number of threads.

When do you see this pattern?

The Single Writer pattern is not only theoretical.

There are many technologies that use this pattern.

LMAX Disruptor

LMAX Disruptor is built in such a way that each piece of the state is written by exactly one writer, thus achieving the speed of millions operations per second.

Redis

Probably the most familiar example.

Redis executes commands through a single event loop.

Because only one thread modifies its internal data structures, Redis doesn't need locks for most of its core operations.

Actor Model (Akka, Orleans)

Each actor owns its own state.

Messages are processed sequentially, so only the actor itself can modify its internal state.

Should You Always Use Single Writer?

Of course not!

In software engineering, rarely anything works all the time, except this statement itself :)

If operations are fully independent and do not access shared state, running in parallel is preferable.

But when multiple threads continuously compete to modify the shared state, the use of the Single Writer pattern can simplify the code and make it perform better.

Note, that this pattern does not exclude the use of parallelism at all.

Actually, the pattern shifts the point of parallelism to the place it makes sense.

Expensive calculations can still be performed in parallel.

But the write to the shared state is done by only one thread.

Conclusion

So, the Single Writer Principle can be formulated very briefly:

Each shared state should have only one writer.

This simple idea gets rid of most challenging aspects of concurrent programming.

No more race conditions.
Locks become unnecessary.
Code becomes easier to understand.
Behavior becomes deterministic.
Throughput is usually improved in cases of contention.

That's why the high-performance system rarely starts with the addition of more threads.

Instead, the following question is asked first:

Can we make the number of writers equal to one?

Page Splits in SQL Server AND Entity Framework

Akbar Dizaji — Tue, 28 Jul 2026 05:15:32 +0000

How does SQL Server store data?

Upon adding the row to SQL Server, it does not immediately write that row to the disk.
It adds the data to the fixed-sized block called Page.

Think of the page as a piece of paper that exists in a notebook with a size of 8KB in SQL Server.

After filling up one page, the remaining rows get added to another page.

What is an Index?

Imagine you have a 500-page book and you want to find the chapter about a topic like .NET, you have two choices:

Start reading from page one until you find it.
Use the table of contents.

The index can be termed as the table of content of the database.
The only difference here is that SQL Server uses B+ Trees for indexes.

Instead of looking at all the rows, SQL Server simply moves down the tree to find the data on the specific page.

This makes the process much faster.

And now the main question:

What is a Page Split?

Suppose a page looks like this:

Page 1

A
B
D
E

Now you want to insert C.

But the problem is that the page is already full and there isn't any space for the new row.

SQL Server has to:

Allocate a new page.
Move roughly half of the existing rows to the new page.
Insert C into its correct sorted position.

Before:

Page 1

A
B
D
E

After:

Page 1          Page 2

A               C
B               D
                E

This is a Page Split.

Why are Page Splits bad?

At first glance, it seems like SQL Server only moved a few rows. But no. In reality, the operation is much more expensive.

More disk writes: Instead of performing a simple INSERT, SQL Server must:

Allocate a new page.
Copy rows.
Update the B+ Tree.

This makes each write operation more costly. And moving rows and updating the B+ Tree also takes extra CPU cycles. Furthermore, when splitting the page, SQL Server needs to briefly lock both the page and the B+ Tree structure. On heavily used databases, this causes extra contention and waits for other processes.

What causes Page Splits?

The most common causes are:

A clustered index built on random GUIDs (NEWID()).
Updates that increase the size of existing rows.
Completely full pages.
An inappropriate Fill Factor.

How can you reduce Page Splits?

*- Use sequential keys:
*
Instead of:

NEWID()
Prefer:

IDENTITY

NEWSEQUENTIALID()
Since new rows are always inserted near the end of the index, page splits become much less frequent.

*- Configure Fill Factor
*
If you know a table receives frequent inserts or row-growth updates, you can intentionally leave free space inside every page.

For example:

FILLFACTOR = 80
This tells SQL Server to fill each page to only 80%, leaving 20% free for future inserts.

But we should remember, a very low Fill Factor isn't always better because it creates more pages, which can increase storage usage and slightly reduce read performance. The optimal value depends on your workload.

*- Rebuild indexes
*
If fragmentation becomes significant, rebuilding the index reorganizes the pages and removes fragmentation.

Fill Factor in Entity Framework Core

EF Core provides built-in support for SQL Server's Fill Factor option.

modelBuilder.Entity<Order>()
    .HasIndex(x => x.CreatedAt)
    .HasFillFactor(80);

The generated migration produces SQL similar to:

CREATE INDEX IX_Orders_CreatedAt ON Orders(CreatedAt) WITH (FILLFACTOR = 80);

Summary

Page Split is a process in which a new row is added to a full page. In order to free up space for the newly added row, a new page is created, the rows are moved to the new page (about half), and the B+ tree structure is updated. The process ensures the maintenance of indexes in sorted form but adds to write overhead, CPU utilization, and fragmentation in heavy workloads. Sequential keys and proper setting of Fill Factor help prevent Page Splits.

Memory-Optimized Tables in SQL Server (Explained Simply)

Akbar Dizaji — Sat, 18 Jul 2026 07:11:06 +0000

Another unique thing about SQL Server is Memory-Optimized Tables. Many people think that the concept of Memory-Optimized Tables is just about storing the data in memory as opposed to storage, therefore making everything faster. Well, this is not completely true.

What do ordinary tables look like?

In an ordinary SQL Server table, data is stored persistently on storage. However, when the SQL Server is going to read or alter any piece of data, it has to load it into RAM (Buffer Pool) first. An INSERT or an UPDATE operation in SQL Server will typically involve alteration of data in memory and subsequent writing to storage.

So even the ordinary tables take advantage of RAM heavily.

What then is special about Memory-Optimized Tables?

Well, it has more to do with how SQL Server handles the data rather than where it is actually stored.

The conventional tables structure data into pages that are 8 KB. Each time any change is made to the data, SQL Server needs to handle the pages. In case there are several users accessing the same data at the same time, SQL Server uses features like Locks and Latches to keep everything under control.

The Memory-Optimized Tables have a completely different internal structure altogether. They do not use pages for structuring data and eliminate most internal overheads. As such, they perform better in highly concurrent workloads.

What are Locks and Latches?

Imagine you have a notebook.

If two people try to edit the same page at the same time, one of them has to wait until the other finishes writing. That's similar to a Lock—it protects the data itself.

Now imagine someone is turning the pages of the notebook. If another person tries to grab the same page while it's being moved, the notebook could be damaged. To prevent this, SQL Server briefly blocks access while it manipulates its internal structures. This is called a Latch. Unlike a Lock, a Latch protects SQL Server's internal memory structures rather than the user data.

Memory-Optimized Tables eliminate much of this waiting.

Versioning

In the case of traditional tables, any changes are usually made directly to the row itself.

However, with Memory-Optimized Tables, changes are not made to the existing row; rather, a new version of this row is generated by SQL Server. The previous version stays there as long as there are no transactions using it.

This enables multiple users to read/write data at once without blocking one another.

What is MEMORY_OPTIMIZED_DATA?

Great and important question. In case if your data is residing in memory, then what will happen if the server goes down?

This is where the MEMORY_OPTIMIZED_DATA filegroup plays an important role.

The MEMORY_OPTIMIZED_DATA filegroup in SQL Server is used to hold all the necessary details required for the recovery of durable Memory-Optimized tables after a restart. This will give persistence to your data.

In other words, this filegroup is not a substitute for RAM, but rather the persistent place where SQL Server can retrieve the data after a restart.

Is it not what the Index does as well?

No.

Indexing just increases the speed at which you locate the data.

In case SQL Server requires locating a user record with the ID equal to 100, an Index will help locate it very quickly.

But once located and when it should be updated, SQL Server will have to work with pages, locks, latches, and all other common methods.

Memory-Optimized Tables enhance a totally different area of the system and its architecture for read/write processes.

That is why in spite of good indexing, Memory-Optimized Tables give considerable performance boosts in systems handling thousands of simultaneous operations.

Do all tables need to be Memory-Optimized?

Absolutely not.

In case when a table holds several thousand rows but is modified only a few hundreds times a day, there will be no advantages to using Memory-Optimized Tables.

On the other hand, they are very useful for applications like:

User sessions storage
Chat programs
Gaming websites
Processing queues
Large-scale financial applications that deal with a huge number of parallel transactions

When there are thousands of actions happening every second, Memory-Optimized Tables may be very beneficial.

Summary

The Memory-Optimized Tables do not represent just another way to "store data in RAM". These are radically new storage structures that have been created with high-concurrency use-cases in mind. Memory-Optimized tables achieve their increased speed through optimization of internal structures and reduction of waiting time between concurrent actions through optimization of data handling in SQL Server's memory. The increased complexity of Memory-Optimized tables, however, makes them suitable for specific use-cases only.