concept CQRS architecture in category entity framework
This is an excerpt from Manning's book Entity Framework Core in Action.
Although software/compute performance is normally the bottleneck on scalability, for applications that make high demands on the database, extra instances of the web application won’t help much. At this point, you need to be thinking about other architectures. This topic is beyond the scope of this book, but I recommend you look at architectures that split the read-only database accesses from the write database access, such as the CQRS architecture.
Because most applications read the database more than they write to the database, the CQRS architecture can help with database performance. In addition, by splitting out the read-only queries to a NoSQL database, you can make the replication of the read-only databases easier, which gives you more database bandwidth. I implement just such an architecture using a CQRS approach in section 14.4, with impressive performance gains.
Figure 14.1 A conceptual view of a CQRS architecture with an SQL database for the write side, and a NoSQL database for the read side. A write takes a bit more work because it writes to two databases—the normal SQL database and the new NoSQL read-side database. In this arrangement, the read-side database is writing in the exact format needed by the user, so reads are fast.
Using two databases is a logical step with the CQRS architecture. It brings potential performance gains for reads, but a performance cost on writes. This makes the two-database CQRS architecture appropriate when your business application has more reads of the data than writes. Many business applications have more reads than writes (e-commerce applications are a good example), so this architecture fits our book app well.
Figure 14.4 On the left, the cached-values SQL performance-tuning implementation developed in section 13.4 fixes the problem of two simultaneous reviews being added, by using EF Core’s concurrent detection and handling feature. On the right, the CQRS architecture handles the same problem by design; it doesn’t need any special handling to cope with this problem.
Unlike the cached-values SQL solution, in which you had to consider each cached value separately and devise a different solution for each, the CQRS design handles all potential problems in one go; it effectively designs them out. In addition, the CQRS architecture helps with the overall design of the system, which is why I think CQRS architecture is worthy of consideration for systems that have more reads of data than writes.