Hacker News new | past | comments | ask | show | jobs | submit login

> Anyway don't over-simplify this use case and believe "a single big SQL ACID transaction would handle the problem". That's just not true.

> In the web age, you want stateless services and HA. It means a transaction can't last more than a single web page. It becomes more challenging to design a shopping cart, because the DB can't handle a long-running transaction anymore.

Or you could cheat and not update the inventory until the purchase is made. ;)

The problem with the "adjust inventory on cart" in low inventory situations is you'll have 80% of your carts holding items that won't convert until a cart expiration. You only need the actual purchase to be atomic. Then, once the queued credit card transaction completes you adjust the order to refund the inventory [declined] or ship the order [completed].

That pattern absolves you of needing complex logic and allows you to distribute the activity relatively trivially as a set of two independent idempotent operations. And if the analog portion of the process fails, the picker hits a button and the order gets queued for a refund. Once the order is cancelled, another service contacts the customer.

Cart expiration, etc. makes the system unnaturally brittle by adding non-critical steps to the process.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: