Real-time Auction Web Application Architecture

[alma]

 am designing a new real-time auction web application, similar to ebay but more specialized. From initial research I feel that a solution based on Node JS/Express JS/Redis or MongoDB would work well.

The auctions will run in real time, and multiple auctions can occur concurrently. Users can also be active in multiple auctions at the same time. Users will submit bids and view the progress of the auction through a web browser, receiving real-time updates throughout the auction. As these are specialized auctions there is a more complex than usual bid methodology that may take a non-negligible amount of processing time when a new bid is submitted.

Having thought through the proposed architecture I realized that independent auctions will end up blocking each other due to the single-threaded nature of Node JS and the databases. For example, consider that there are two live auctions; Auction A and Auction B. If a user submits a bid in Auction A, whilst this bid is being processed by the server another user is essentially blocked from submitting a bid in Auction B. This is not ideal as the two auctions are completely independent of each other and do not share any state. As the site hosts more concurrent auctions this delay will increase.

Is there any way that I can architect the application so that this is not the case and that multiple auctions can run in a truly concurrent fashion?

One idea that I had was to somehow dynamically create a new instance of the application along with its own database on the creation of every new auction. I am unsure how practical this is or if there are other tried and tested techniques for dealing with this kind of problem.

A further consideration is to be able to scale the application as demand grows.

Any advice would be greatly appreciated.

[Ryan Schmidt]

On Mar 7, 2014, at 22:12, alma wrote:

> Having thought through the proposed architecture I realized that independent auctions will end up blocking each other due to the single-threaded nature of Node JS and the databases. For example, consider that there are two live auctions; Auction A and Auction B. If a user submits a bid in Auction A, whilst this bid is being processed by the server another user is essentially blocked from submitting a bid in Auction B. This is not ideal as the two auctions are completely independent of each other and do not share any state. As the site hosts more concurrent auctions this delay will increase.

Such delay will only be the fraction of a second it takes to start processing the web request. In the likely event that your request involves database transactions or any other asynchronous data gathering, control will be returned to the libuv event loop while the data gathering occurs, freeing up the event loop to handle other web requests.

I really don’t think the problem you’re envisioning will be a problem for you at all.

> Is there any way that I can architect the application so that this is not the case and that multiple auctions can run in a truly concurrent fashion?

Use a multiple-core server computer and run multiple copies of your node application via the built-in cluster module or other similar method, or even run multiple copies of the node application on multiple physical servers.

All these copies of the node application can connect to the same database server. If performance becomes a problem, the database server could be on its own physical server, or be distributed among multiple physical servers.

In short, you’d plan to scale your node web servers, and your database servers, separately, as needed.

[Alex Mady]

Thanks for your reply, that is certainly reassuring. 

—
Sent from Mailbox for iPhone

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/DlTh6UnHpw0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.