Event sourcing/storing with SAGA

(please correct me if i am wrong or something is missing)

Event sourcing helps in storing all the changes (events) to the system, rather than just its current/latest state, means we can persist different version(change history) for for any domain object. So we can see the audit trail and or back track(roll back) to an early stage.

Questions: (a) So in future do you have any plan to use SAGA to demonstrate the roll back among multiple micro-services?

(b) Kindly also explain the realtime usage of IsReplaying property

    public class WorkshopPlanning
    {
        /// <summary>
        /// Indication whether the aggregate is replaying events (true) or not (false).
        /// </summary>
        private bool IsReplaying { get; set; } = false;

and of course thanks again for your wonderful help and support - I am highly obliged and grateful to you!

_Originally posted by @findkashif in https://github.com/EdwinVW/pitstop/issues/42#issuecomment-538516625_

[CodeWithKashif]

Yes I was not talking for ACID transaction and i was referring something like https://dzone.com/articles/distributed-sagas-for-microservices Here it has given very common and famous example of flight, car and hotel booking example. and mentioned clearly: “With the microservices approach, you can’t just book a flight, a car, and a hotel in a single ACID transaction. To do it consistently, you would be required to create a distributed transaction.”

…and yes I also see/agree it is doable with current architecture setup with Pitstop, just wanted to check with you whether do you have any future plan to find-out & implement any such example for demonstration purpose.

[EdwinVW]

(a) I’m not sure I get your saga question. I know sagas as a way to orchestrate a process that spans multiple microservices. I would not use the eventstore to do rollbacks. Only “roll-forwards”. If you need to fix anything in an event-sourced service, you add events to correct things (like an accountants ledger). Such a correction could be part of a saga (as a compensating action).

(b) The IsReplaying indication is set when we are replaying events from the event-store to rebuild the state of the aggregate (using the set of events received from the database and passed to the constructor). This offers us the opportunity to change behavior in the event-handlers when replaying. I have not used this in Pitstop, but this is standard pattern I always use. I have used it once in a different situation to disable logging of event-handling during replay.

Again, I hope I’ve answered your questions 😃