CQRS why not just have elasticsearch for both read and write?

Question

I am thinking of having a CQRS architecture for my project. This means having a read and a write database and an update process to keep both databases in sync.

Since I am going to update the read (elasticsearch) database anyway after each command, I wonder: what is the use of having a write database at all?

Answer 1

The purpose of seperation is distributing load accross multiple databases. Use one write optimized database for write operations and update read optimized database as asynchronous. So this way, write load is not affects read database. We can scale them independently.

Another reason is read and write schemas may be differ. You can have a blog site which lists recent blogs on home page, you need to write all data to write database but you need only some of the data for listing or indexing it. Hence, using CQRS on infrastructure level provides us to independent scalability of databases.

Answer 2

I know this topic is more then 3 years old but I like to tell my 2 cents, for the same problem I developed an Event Sourced Akka Finite State Machine with Cassandra to deal Command/Write Side of the CQRS.

As the previous, I have the agree that write side model and read side model, does not have to be the same, in my State Machine there are more then 30 States but only 5 of those are only interesting for Read Side.

If anybody like to see how it is done, I wrote a Blog about it Akka Finite State Machine with Cassandra/Elasticseach for CQRS