unclearness about event sourcing

Question

how i know the concepts about event soucring that important events of app are stored on event store databases. but there are many prallel questions.

1) how main DB works in this application? for example when wi store a data like (player transaction added 100 golds) how main database that stores current state of player/user should be used. can i do a CRUD to update the main database in other microservices or its different?

2) how SAGA benefits from event sourcing. does it benefit at all? for example when one of the microservices failed and we want to compensate the whole scenario, do we need to use event sourcing for that or an inner state memory is enough?

3) what is the best practice saving user events in event stores? as you may know event stores can get very big soon. assume that based on some condition we want to remake a user current state from its events? what is the right approach?

Answer 1

Event sourcing and the saga pattern are an approach to handle distributed transactions, especially when a acid distributed transaction manager is not supported, as is the case with micro services and some document databases.

With an acid transaction manager, all the distributed services support begin transaction and commit transaction. Also the update will not return until all transactions commit or fail. On failure a rollback is done.

The event sourcing pattern uses a persistent queue instead of a distributed transaction manager. This allows the calling transaction to complete as soon as the queue entry is done and leads to higher scaling, with the trade off that the transaction will complete some time in the future.

The saga pattern allows processing of a queued transaction to produce more queued transactions.

The main design difficulty with event sourcing is handling failed transactions. A event workflow needs to be designed.