Design Question - Controlling registration in high concurrent user situation with very short duration registration window

[gregincolumbus]

I am trying to determine the best option for controlling registration for courses where there is a hard limit of attendees per course and about 300 concurrent users trying to register for them at the exact same time (when the window opens for registration).

The 66 courses will fill to capacity in the span of about 6 to 7 minutes....so as you can imagine, the server will be hit pretty hard. It has the capacity to handle the load, but I am most concerned about making sure that each course is no longer available once it reaches its seat capacity limit. The users all have a profile already and are logged in so there is nothing being collected from them at the time of registration...they literally click the register button ....which means lots of hits to the server in a very short amount of time.

My plan is to build a view in MySQL that has a COUNT field to count the registrations in the registration table. The view also has a column for Seat Capacity for the course. A viewbox to display the courses and register button seems to be the lightest option. The register button would perform an Ajax callback to determine if the course was still open...if it was, then it would do a sql insert into the registration table using XBasic...otherwise it would refresh the viewbox to hide the button and show a message the course is at capacity. I would use client side templating to show or hide the button or message based upon the result of the callback.

Does this seem like a reasonable option or does someone have a suggestion on how to better handle this situation. This goes live on June 1st, so I need to come up with a solution fairly soon.

Thank you in advance for any advice or suggestions!

[lgrupido]

You will likely get over-registrations using that system. Consider this: A course has a capacity of 60 and 59 are currently registered.

Two users now click the register button for the course at the same time - not an unlikely occurrence in your scenario. Both of their views will show an opening because neither insert has happened yet and then both of their inserts will hit the system at the same time. You can setup a trigger to disallow one of their registrations, but even that can be fraught with peril.

What you need is to setup a queue system. When someone presses the register button, their selection goes into a FIFO queue. On the server, you have a process that checks the queue one record at a time. For that record and that course, it checks availability and registers the person before going on to the next person.

This can happen live or it can happen offline. For offline, the person submits their registration and waits a few minutes for an email to see if they got in.

For live, their computer waits for the server to send them back a signal that their registration was successful or not. (Depends on how you setup the queue and how quickly you can actually process the queued registrations.)

Does that make sense?

[gregincolumbus]

Thank you for taking the time to reply. That does make sense....a live implementation would be needed since the user will want to go to a different course as quickly as possible if their first choice was not honored. I have never implemented a FIFO approach...so I will search the boards and see what I can find. Thank you for the suggestion!