I agree with you in spirit, but it's simply inaccurate to suggest that a shopping cart does not deal with mission critical data.
the fact is, Amazon does use Dynamo for a mission critical financial purpose. If Dynamo lost data Amazon would not use it for arguably one of the key pieces of their success.
the article I linked covers how they do this, and how it stays accurate, scalable, and robust.
anyways cheers, I hope we have not hijacked this thread about MySQL bugs too much.
First of all, any single shopping cart is typically accessed by one single process at a time: the user's browser. I can of course open two or more browser sessions, but this is not a typical use case, it definitely has an upper limit (how many browser tabs can I use concurrently?) and most importantly, lost or duplicated transactions are easily spotted and corrected (you do get plenty of chances to revise your order before paying).
A bank account can be "hit" by different sources at the same time (just think of a company bank account, not just a personal one) and most importantly, duplicated or lost transactions are much harder to prove and rectify.
The browser tabs have an upper limit sure, because on the client/browser side, it just might be unfeasible to open more than 100 tabs realistically.
But, I can assure you, you could open 1000 tabs, and dynamo will be fine, and not lose your data.
You should really read the article I linked, especially the part about vector clocks, it discusses a common approach for dealing with duplicate data, conflicts, and resolution, at scale.
Comments
Well, the shopping carts do not contain data which must be correct so your example does not contradict Pamar.
I agree with you in spirit, but it's simply inaccurate to suggest that a shopping cart does not deal with mission critical data.
the fact is, Amazon does use Dynamo for a mission critical financial purpose. If Dynamo lost data Amazon would not use it for arguably one of the key pieces of their success.
the article I linked covers how they do this, and how it stays accurate, scalable, and robust.
anyways cheers, I hope we have not hijacked this thread about MySQL bugs too much.
I am afraid we are comparing apples to oranges.
First of all, any single shopping cart is typically accessed by one single process at a time: the user's browser. I can of course open two or more browser sessions, but this is not a typical use case, it definitely has an upper limit (how many browser tabs can I use concurrently?) and most importantly, lost or duplicated transactions are easily spotted and corrected (you do get plenty of chances to revise your order before paying).
A bank account can be "hit" by different sources at the same time (just think of a company bank account, not just a personal one) and most importantly, duplicated or lost transactions are much harder to prove and rectify.
The browser tabs have an upper limit sure, because on the client/browser side, it just might be unfeasible to open more than 100 tabs realistically.
But, I can assure you, you could open 1000 tabs, and dynamo will be fine, and not lose your data.
You should really read the article I linked, especially the part about vector clocks, it discusses a common approach for dealing with duplicate data, conflicts, and resolution, at scale.