[gav]

I feel like the e-commerce inventory example isn't a great one because the problem is generally solved by avoiding it.

Either:

Set the inventory amount in your e-commerce system to be less than the actual inventory (which is rarely accurate anyway). This is your safety stock and depends on how fast moving the item is and if it's a close-out that you are really trying to sell to zero. Then just handle exceptions at allocation-time when you're able to commit stock.

Or:

Avoid a two-phase commit problem by allocating stock at add-to-cart time with a ticketing system that allows a hold to be placed with a timeout. This is a more customer friendly approach that handles stampedes better, such as caused by marketing emails.

Either way, inventory management is like banking, aiming to be eventually consistent is a lot more realistic than being always consistent.

[hangonhn]

"Either way, inventory management is like banking, aiming to be eventually consistent is a lot more realistic than being always consistent."

Yeah I love those basic DB examples of transactions and why it's important using bank accounts when in real life banks are all eventually consistent because they had to solve the problem before distributed transactions were available.

[ratneshsingh35]

Thanks for sharing, If you include scale then the situation might be tricky, you may need to have different DBs and endpoints there will be a limit on how much vertically you can scale, with that thing in mind this problem is not avoidable, but the distributed transaction is still avoidable using eventual inconsistency or a batch proces.