Event Store logo

sss https://eventstore.org Menu

Developer Blog

How to avoid Dirty Reads with Event Store

   |   Riccardo Di Nuzzo

Dirty Reads are not frequent but are possible with the default Event Store configuration. In this article, I discuss why they occur and how to avoid them.

When a client sends a write to an Event Store cluster, the master writes the events and replicates them to the other nodes in the cluster. The master then waits for a quorum of nodes (cluster size/2 + 1) to acknowledge the write before considering the write successful.

For example, in a cluster of 3 nodes, the quorum is 2 nodes. Before the Master can send back an acknowledgment to the client, it needs to wait for the confirmation of a write from at least 1 Slave node. Because of this, it is possible that a client can read from the other node that is not yet updated with the latest write. This situation is called a “Dirty Read”.

If you need to ensure that a client always reads the latest version of your data, then you can do the following.

.NET Client

Use the PerformOnMasterOnly() builder method, or the RequireMaster setting in your connection string:

var connectionString = "ConnectTo=tcp://admin:changeit@localhost:1113; RequireMaster=True"

HTTP Client

If your client doesn’t provide this method, use the ES-RequireMaster HTTP header via your client:

curl -i "http://127.0.0.1:32004/streams/newstream" -H "ES-RequireMaster: True"

The syntax varies from client to client but look for a parameter or method that matches and for instructions on how to use it.

Configuration Counts

In conclusion, the possibility of a Dirty Read depends on your connection settings and if the cluster can read from any node, or read-only from master. Make sure your settings are optimised to avoid them.