I am assuming a system where available inventory is debited when the CC transaction completes.
How do you do that with single row only atomic transactions? And without charging $100 for what the customer thought was qty 3 $25 rakes and qty 1 $25 shovel...but is now something less than that due to concurrent purchases from other customers?
"How do you do that with single row only atomic transactions?"
In this scheme, you should theoretically be able to implement transactional protocols (two phase commit and friends, see, e.g., http://dl.acm.org/citation.cfm?id=3027893) that ensure you do not actually sell two people the same thing, but may return an error at buy time that the inventory disappeared while you tried to buy it.
You pay a sometimes-very-high cost in throughput.
Of course, talking about mongodb, it's probably broken in a myriad of ways no matter what you do :)
It was a distributed system. The inventory was kept in Mongo with atomic debits and credits applied with a bus in front. SQL existed for the actual order, but inventory was managed in Mongo fine.
I'd like two of this product? Increment reserved in Mongo atomically, fire a bus message that inventory was reserved. I'd now like just one? Again atomically remove one from reserved and fire another message. Simplified of course.
Two users can't reserve the same inventory, reserving the inventory is atomic, and everyone else occurs during reconciliation. Typical distributed systems.
So you can't have exactly once semantics. When you say 'bus' I assume you mean a message broker which at best gives you at least once semantics. What happens when the message is delivered multiple times?
That's just a broker; all message handlers must be idempotent. This sometimes means storing message IDs or creating one-direction state change conduits that fail subsequent duplicate messages.
To answer that question more succinctly, nothing special happens when a message is delivered more than once.
I would assume you propagate a transaction ID or expected row version (and persist transaction histories and/or version numbers along with the inventory item row after mutation).
And what happens when that shovel gets stolen from the warehouse before it can be shipped to the customer?
You have to handle over-selling no matter what. The "source-of-truth" of you inventory system is whatever is actually, physically sitting in a warehouse somewhere. Not what your database says.
I think Amazon calls it Apology Based Computing or something like that. You're better off at scale writing out a transaction log, then seeing if actions were successful and compensating otherwise.
Comments
I am assuming a system where available inventory is debited when the CC transaction completes.
How do you do that with single row only atomic transactions? And without charging $100 for what the customer thought was qty 3 $25 rakes and qty 1 $25 shovel...but is now something less than that due to concurrent purchases from other customers?
"How do you do that with single row only atomic transactions?"
In this scheme, you should theoretically be able to implement transactional protocols (two phase commit and friends, see, e.g., http://dl.acm.org/citation.cfm?id=3027893) that ensure you do not actually sell two people the same thing, but may return an error at buy time that the inventory disappeared while you tried to buy it.
You pay a sometimes-very-high cost in throughput.
Of course, talking about mongodb, it's probably broken in a myriad of ways no matter what you do :)
Nailed it, but I'm curious where you think the throughout suffered; we didn't encounter that problem.
It was a distributed system. The inventory was kept in Mongo with atomic debits and credits applied with a bus in front. SQL existed for the actual order, but inventory was managed in Mongo fine.
I'd like two of this product? Increment reserved in Mongo atomically, fire a bus message that inventory was reserved. I'd now like just one? Again atomically remove one from reserved and fire another message. Simplified of course.
Two users can't reserve the same inventory, reserving the inventory is atomic, and everyone else occurs during reconciliation. Typical distributed systems.
So you can't have exactly once semantics. When you say 'bus' I assume you mean a message broker which at best gives you at least once semantics. What happens when the message is delivered multiple times?
That's just a broker; all message handlers must be idempotent. This sometimes means storing message IDs or creating one-direction state change conduits that fail subsequent duplicate messages.
To answer that question more succinctly, nothing special happens when a message is delivered more than once.
At least, when we didn't screw up :)
Those were fun days.
I would assume you propagate a transaction ID or expected row version (and persist transaction histories and/or version numbers along with the inventory item row after mutation).
And what happens when that shovel gets stolen from the warehouse before it can be shipped to the customer?
You have to handle over-selling no matter what. The "source-of-truth" of you inventory system is whatever is actually, physically sitting in a warehouse somewhere. Not what your database says.
Yes, you have to handle overselling for other reasons, but I don't see why that's a good reason to not protect against it when you can.
I think Amazon calls it Apology Based Computing or something like that. You're better off at scale writing out a transaction log, then seeing if actions were successful and compensating otherwise.