Hi Greg, Things are more tricky in an eventually consistent distributed system than they are in a relational database. Even if the C* triggers were perfect (and they are not) and your write and read tables were exactly the same, there is no guarantee that all the updates created by the trigger from the original mutations will be successfully delivered to your other table and there are no entropy mechanisms to repair those problems. Overtime the data in your write and read tables will just start to diverge.
On Mon, Dec 14, 2020 at 2:02 PM Greg Oliver <gol...@microsoft.com.invalid> wrote: > Hi all, > > My customer wants to use Cassandra together with the CQRS pattern. This is > to say, they want to separate reads and writes to different tables, > potentially in different keyspace or database. > > In my experience with relational databases I would set up a trigger on the > "write" table such that on new row & update row events, a similar row would > be inserted into the "read" table. > > I found a few examples of setting up a trigger on a Cassandra table and > have replicated that on my system. But in reading the various Stack > Overflow posts on the topic a persistent message saying "don't do it unless > you really know what you're doing" pops up. > > Why? What are the cases for and against using triggers in Cassandra? What > are the edge cases to avoid? What is the happy path? > > Thanks, > Greg >
