-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Description
I was checking the flow of order completion and noticed that when an OrderStatusChangedToAwaitingValidationIntegrationEvent is consumed by the Catalog service, it performs a check (without locking the DB) to see if there is stock for the items in the order. If stock is available, an OrderStockConfirmedIntegrationEvent gets published and payment is processed. After that, an OrderStatusChangedToPaidIntegrationEvent is published and handled by the Catalog service, this is the point where the stock actually gets removed for the ordered items.
To me, it looks like this could cause issues when two OrderStatusChangedToAwaitingValidationIntegrationEvent events are processed for the same product at the same time, or when one is already close to finishing the payment process. This might result in "overselling".
A simple solution would be to remove the stock right when the Catalog handles OrderStatusChangedToAwaitingValidationIntegrationEvent, which would also lock the row in SQL.
I know this isn’t a big deal since it’s just a reference app, but I was curious to know why it was designed this way, instead of “reserving” the stock during validation and then re-adding it if payment fails.