Difference b/w cqrs and master-slave architecture?

Question

As per my understanding -

CQRS is like separating reads with writes. But we can do the same with master-slave architecture as well. Assuming master for writes and slaves for read req.

So I want to understand when should we use CQRS and master-slave architecture?

Answer 1

Master-Slave architecture often deals with the physical separation and replication of data, for better availability and reliability. While the data model itself remains the same for the master and slaves. We can divide the responsibility of reads and writes between masters and slaves, but they still deal with the same underlying data model and interfaces.

On the other hand, the CQRS design pattern is more about decoupling the read and write data model and interfaces themselves, allowing them to evolve separately, and avoid an overly complex model that does too much. The read and write operations in CQRS may even be powered by two completely different data stores with very different schemas

CQRS:

• https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
• https://martinfowler.com/bliki/CQRS.html

Answer 2

So I want to understand when should we use CQRS and master-slave architecture?

A good starting point would be Greg Young 2010.

CQRS is simply the creation of two objects where there was previously only one.

When most people talk about CQRS they are really speaking about applying the CQRS pattern to the object that represents the service boundary of the application.

This separation however enables us to do many interesting things architecturally, the largest is that it forces a break of the mental retardation that because the two use the same data they should also use the same data model.

The last is, to my mind, a key distinction; we're not talking about multiple replicas of the same data model, with some dedicated to supporting reads, but instead about having the same information stored in two different data models.

A common example would be to use a data model based on event histories for writes, with reads instead being served by generating result sets from an RDBMS.