This is not a real scenario. This is just my assumption that such an accident may happen if the the following events really occur in this chronological order
First, a user clicked "puchase" on an item which says "$100" on a web browser (frontend). The request is being sent to the API server. This may take quite a long time due to a laggy internet connection, etc. Let's call this request A.
In the meantime, a staff just updated the price of that item, to let's say $200, and the database already successfully changed the price of the item. Assume this change is so fast because of a smooth internet connection. let's call this request B
When request A just hit the backend, the price change has already been executed. Even databae locking mechanisms such as "transaction" seems to be helpless in this scenario. Because, while request B sql is already executed in the database, request A has not yet hit the database or even the backend due to a slower internet connection. So the database is not aware of the existance of request A during the execution of request B sql.
This is a serious problem. The user is shown that the price is still $100 on the website at the moment he clicks purchase. But when the request is processed, the poor user is not aware that he is charged $200. Even though he may notice it later from an invoice, he could already prejudge this company is a scam and tell this story to his friends. This would undermine the reputation of the company in some way.
To avoid such accidents, tempoararily blocking the purchase API is a solution, yet impractical.
Is there a better solution? Like some sort of real time check between the backend and database to stop request A from proceeding?