Building an English Auction With MongoDB(artsy.github.io)
artsy.github.io
Building an English Auction With MongoDB
http://artsy.github.io/blog/2014/04/17/building-an-english-auction-with-mongodb/
2 comments
SQL would certainly have been an adequate solution for this. In our case (I work at Artsy and contributed to the code described in the post), our environment relies primarily on MongoDB already.
I think the work is interesting precisely because it achieves some of the benefits of transactional systems using a data store that isn't usually considered for these purposes. Immutable documents and serializing the processing of bids (to limit concurrent access), as described in the post, helped.
I think the work is interesting precisely because it achieves some of the benefits of transactional systems using a data store that isn't usually considered for these purposes. Immutable documents and serializing the processing of bids (to limit concurrent access), as described in the post, helped.
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?
> 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?
The 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.
i 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")
From the perspective of iOS bidding we copied all the data models and had to do no hard thinking other then being responsive to API changes.
Not trolling, I'm genuinely asking.
I've been trying to gather objective information from people who have actually been successful with mongo about exactly why mongo was the best tool for that job.
http://daemon.co.za/2014/04/when-is-mongodb-the-right-tool