Open NicolasRouquette opened 5 years ago
Checking of duplicate transactions should be responsibility of Account service. In general check could be done using these solutions: 1) using read side (store transactions via readside processor) 2) using write side (store last few transactions in state)
Problem with solution #1 is eventual consistency. Transaction may not yet be stored when duplicate is received. And risk, in this case, is high. So, as you have suggested, transactions should be stored in state. It is not optimal to store all so there should be a time and/or number limit. For example 5 transactions in 10min. Check can be done on state update (addTrasaction). Nicolas would you like to send PR for this?
What would happen if the transfer service were to somehow restart in the middle of a transaction? Replaying events could lead the
TransferSagaReadSideProcessor
to re-issue the same commands to the account service:removeFunds
,addFunds
, orremoveFundsRollback
.As implemented, these commands will unconditionally perform the same side effects whenever the same events are replayed -- i.e., funds could be added or removed multiple times, which is clearly not the intended semantics.
It seems that the account service should implement an idempotent semantics for account-related commands; that is, perform the command only if the transaction has never been seen before, otherwise ignore the command.