Juhan, just so that I interpret you correctly in "The current problem however is that there are some commands that when they get executed, they create other commands as a result (when you replay such a command you will create a command again - although it exists already)"
These "other commands" can be either of two types: 1. Commands that just lead to further state changes in the database and that these changes do not lead to other side effects. (The state of which we wish to restore after a disaster) 2. Commands that not only lead to state changes in the data base, or state changes that lead to side effetcts. Examples : Email sent to customer, calls to other services that mutate state. I interpret your comment to be about the standard issue of not getting these side effects again during disaster recovery. Correctly understood? I just want to point to the fact that in an event sourced system this problem goes away since the events that are replayed only serve the purpose of building up the application state . Best regards Niklas [cid:[email protected]] Niklas Uhrberg Konsult IT Development | Loans & Credit Resurs Bank AB Växel: +46 42 38 20 00 E-post: [email protected]<mailto:[email protected]> Webb: www.resursbank.se<http://www.resursbank.se> ________________________________ From: Juhan Aasaru [[email protected]] Sent: Thursday, October 24, 2019 6:43 PM To: Victor Romero Cc: Dev; Niklas Uhrberg Subject: Re: Usage of Cassandra in Fineract CN Hi! I just recently learned that this design would also help on recovering from a disaster. Cassandra can be easily replicated so the risk of loosing all the Cassandra nodes is relatively small. And even if that happens you only loose the commands that are not executed yet (not a huge problem since any command could fail after it is issued). Postgres can also be replicated but at one point the database (and replica) could become corrupt. So you restore it from the recent backup but you face the problem that the backup is probably at least several hours old. To solve the issue you could replay the commands in Cassandra to bring the database restored fromt the backup to the lasest state. The current problem however is that there are some commands that when they get executed, they create other commands as a result (when you replay such a command you will create a command again - although it exists already) So there should be a mechanism in place in Fineract-CN to identify such commands so one could skip executing them during replay (or some other stattegy to deal with this). Juhan Kontakt Victor Romero (<[email protected]<mailto:[email protected]>>) kirjutas kuupäeval N, 24. oktoober 2019 kell 17:28: Yes it is. https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+Project+Structure#FineractCNProjectStructure-cassandra El 24 de octubre de 2019 a las 08:11 AM Niklas Uhrberg <[email protected]<mailto:[email protected]>> escribió: Hi! I didn't pay much attention to the Cassandra database when looking at Fineract CN, but now I read https://cwiki.apache.org/confluence/display/FINERACT/CQRS+in+Fineract+CN and I conclude from this documentation that the only usage of Cassandra is to persist the commands. Furthermore that one and the same database is used in the processing of the commands , i.e. the state changes in the Postgres db as a consequence of a command being processed occur in the same Postgres database used to serve read style requests (since there is only one Postgres db) Is this correctly understood? Best regards Niklas [cid:16dfe99108610b9e12a1] Niklas Uhrberg Konsult IT Development | Loans & Credit Resurs Bank AB Växel: +46 42 38 20 00 E-post: [email protected]<mailto:[email protected]> Webb: www.resursbank.se<http://www.resursbank.se>
