DB Read Replicas CQRS

Giriş

Bu seviyede veri de iki kısma ayrılabilir. Açıklaması şöyle.

In a CQRS pattern, the Read data is separated out from the Write data. Read data can then be scaled out infinitesimally, and whenever there is a change in the Write data, its corresponding Read data has to be synchronized.

Açıklaması şöyle.

The implementation complexity increases and there is a major concept to be implemented:

model synchronization: synchronously or asynchronously, the events produced by the commands must trigger a refresh of the read database

Moreover, your event system has to be externalized for example as a message bus (Kafka, RabbitMQ). It will help you to safely keep your messages being processed.

Bir çok veri tabanı read replica için araçlar sağlar. Hatta bazılar consistency desteği bile veriyor. Açıklaması şöyle

Read Replicas provide different read database that contains a read only copy of the main write database.

The services can use different querying model in the code since the database structure is exactly same as write database.

This pattern is used to offload the write database from queries to balance the query traffic across one or more read instances.

Replication tools are usually provided by the DB vendors like IBM DB2, Oracle. Newer cloud-native, managed databases provided read replicas as managed service and takes care of replication and high availability of the read replicas.

In specialized cases the DB replication can also be tuned for strong consistency (aka a replication-factor). In which case the replication is done to favor strong consistency model (the C in the CAP). For example, AWS S3 provides strong read-after-write consistency model. Cassandra provides configurable read consistency levels settings.

Şeklen şöyle. Burada veri tabanı da iki kısma ayrılmış durumda. İkisi arasında senkronizasyon gerekiyor.

Senkronizasyon asenkron olduğu için "Eventual Consistency" oluşuyor. Şeklen şöyle

Açıklaması şöyle

In CQRS, when the write operation is persisted, an event is stored in event-store. This event is used to update the read store asynchronously. Events can also be replayed multiple times according to requirements to create different types of query stores.

As the read store is updated asynchronously at a later time, it will result in an Eventual consistent system. Eventual consistency provides high availability and better performance by sacrificing the strong consistency. CQRS will also eliminate the requirement for distributed transactions if eventual consistency can be accepted.

Böylece her iki veri tabanına Write ve Read API'ler ayrı ayrı verilebiliyor. Şeklen şöyle. Bu şekilde "Axon Framework" kullanılıyor

Diğer

Bu seviyede artık Event Publish ve CDC (Change Data Capture) da devreye girmeye başlıyor

Event Publish için açıklama şöyle. Command kodu veri tabanındaki değişikliği aynı zamanda bir kuyruğa yazar.

Many event-driven patterns compliment CQRS style applications. The command services write to a command database. So, any domain event that changes the state of the domain is a command and is written to a database optimized for writes. Command database may also be read for a read-before-write case transitionally, but that is usually within a small context of an aggregate. 

In addition, the command service also publishes the command into a messaging system and a command event with canonical event structure.

This event can be subscribed by any service and in this case, a query service subscription listens to the event and builds a local database that is optimized for reads. As opposite to DB replication, this approach provides the freedom to project the event in any read-optimized way. Indeed, event the choice of underlying database can be different from the command database, thus enabling a polyglot persistent.