I was investigating Durable Objects (DO) and had Fable walk me through where in my app they might be appropriate. One place had a dependency with billing (where I use a transaction now) and the proposed re-work to allow for concurrent editing with DO looked very much like this, reservations with idempotency keys. And if you add hierarchical allotments then it scales pretty well.
replyI disagree with the other posters about the bg process, if you have any bg processing already you should be able to handle the few edge cases without too much trouble.
My understanding is: your proposal is not very different from what Shopify is doing except they are tracking 'reserved units' (one per row) and you are proposing tracking 'orders' as the temporary state to then reconcile back with inventory quantities.
replyYes, at a high level. It doesn't rely on skip locked, which is not cheap at DB level. DB has to still typically run query and keep going until it finds an unlocked item. Deducting and checking inventory counts are simpler ops inside the DB.
replyThis seems like what triggers are for and how we do similar type things. Update trigger on order does select for update on the inventory and increases/decreases it as appropriate.
replyI don't think you really need that even. An indexed lookup is fast and you don't need to store a computed quantity generally.
The moment you added a background process you just replaced the complexity.
reply1. Backgrounds process can back up
2. They need context of the user and need to switch context per user
3. What if they fail, you create some DLQ or another process to handle the failure
4. Who looks on those failure and how do they act
TLDR; there is always a cost
The design in the shoppify post already had a background process for the item replenishment.
replyCan you clarify why this involves no locking? There can still be 2 actors fighting for the same row.
replyTwo concurrent deductions of inventory do contend but only during the actual DB update. That is just normal DB locking for SQL isolation levels. The blog refers to explicit locking by the app, which is where skip locked comes in.
replyYes, the point is to spread contention across multiple rows. They also mention this in the beginning of the article
replynow you have two problems. what happens when your reservation system backs up?
reply[dead]
reply