

Building an English Auction With MongoDB - orta
http://artsy.github.io/blog/2014/04/17/building-an-english-auction-with-mongodb/

======
AdrianRossouw
So why would SQL not have been a good enough solution to this?

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](http://daemon.co.za/2014/04/when-is-mongodb-the-right-tool)

~~~
AdrianRossouw
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
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.

------
orta
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.

