3 ms·
just so we're clear. I did read the article, but not the linked paper. > I spent a fair amount of time visiting engineering teams that have built internet auct
by AdrianRossouw 13y ago
just so we're clear. I did read the article, but not the linked paper.
> I spent a fair amount of time visiting engineering teams that have built internet auctions, most of which were transactional systems where taking a position on an item involved starting a transaction, running an auction round and committing the changes.
That sounds pretty straight forward, where are the pain points?
>In contrast, we chose to deliver a simpler, eventually consistent system on top of MongoDB, in which all data is immutable and where some level of serialization occurs within a single background process.
why was that simpler? what was stopping you from just inserting records instead of updating them? and why did it matter that serialization occurs in a single background process?
- dblock 12y agoThe most common pain point of a transaction-based system was that under heavy load (think stock market load, not @artsy) opening a position would hit a single bottleneck, which eventually becomes too slow given the amount of logic that needs to go into executing a single round.
- dblock 12y agoi think i meant serializing (pardon my english), it's just a way to avoid needing a transactional database (which isn't that big of a deal, we're just trying to say that it's possible to build such a system with MongoDB - you'd be surprised how many times I heard "you won't be able to build a bidding system with mongodb, you need transactions")