Withdrawal Concurrency

[jasoneisen]

I do not see any guard or pattern that ensures that two withdrawals occurring at the same instant will fail one if the first to commit sends the balance to zero. The current implementation appears to be a common read/compare/write without regard to any other debits that may be in flight.

Is this intended or out of scope for this project? This is a somewhat non-trivial but very common use case that I think this project could further shine in by showing one or more best practices and the impact on architecture.

[ivanpaulovich]

Hi @jasoneisen,

Thanks for pointing it out! At this time there is not transaction between reading the balance and updating it.

One possible approach is to change the current Unit Of Work to include a transaction scope for the reading and update repositories.

Would you suggest a particular approach? I am interested into implementing it.

[jasoneisen]

Hi @ivanpaulovich

A transaction could be one approach for pessimistic concurrency control. Off the top of my head, another option would be using EF Core's rowversion for optimistic concurrency. These would be the simple approaches, each with their own trade-offs. A more engineered approach could be some kind of partitioned bus or queue that ensures FIFO within the scope of an account id - though this pushes the complexity into the infrastructure and might make the local development story a bit more difficult.