views:

85

answers:

1

My organization is building a new version of our ticketing site and is looking for the best way to build an online waiting room when the number of users in our purchase path exceeds a certain limit. The best version of this queue would let new users in after existing users have either completed their purchase or have exceeded a timeout limit after entering the path.

I'm trying to get an idea of how this has been implemented by other organizations. Has anyone out there done something similar or have any experience with this? We have some ideas, but I'd like to get a sense of what solutions have been tried and what problems those solutions have run up against.

Just to be complete, this site is being built in Ruby on Rails, though I'd love to hear about how people have solved this regardless of platform.

Edit: To clarify: The need for the queue is not primarily to reduce load, but to limit the speed at which the web is purchasing tickets relative to people buying in other ways, like over the phone.

+4  A: 

Before I outline one method for this, I want to point out that what you want to do doesn't make a lot of sense. Services on the web aren't like a physical store, where I can walk up and see that it's crowded and decide to stay or not. Queueing people on your site strikes me as shifting the blame from you (unable or unwilling to adequately provision resources) to me (punishing me for trying to use your site).

If you're selling something like show tickets, where quantity is limited and each item is tied to a seat, I think it's better to reserve items and time out those reservations if they aren't paid for in a timely manner. Ticketmaster does this, and I think it's a much better solution than blocking people at the door.

If you still want to go down this path, then I'd design the system like this:

As customers come to your site, record their arrival time. As they interact with the site, record a "last seen" time. "Last seen" will be used to determine activeness. You'll need a background job running very frequently to expire sessions quickly.

Once your limit is hit, you have an ordered queue of people who are blocked. As customers complete their transaction or time out, you'll mark the next person in the queue for entry into the purchase path.

For queued users, their browsers will make a request on a regular basis, checking to see if you've let them in yet. If yes, they proceed to the purchase path. If no, they continue to wait.

The purchase path needs a mechanism to check if someone is trying to circumvent your waiting area, and sends them back.

Steve Madsen
We have one system related need for this (our 3rd party ticketing app's seat server has a hard session count limit we cannot increase) and one business need for it (to prevent web users from buying all the tickets in the first 5 minutes so that people on the phones have a shot, too). This isn't meant to reduce server load.We have the reservation timeout functionality you described, which kicks in in the purchase path. This would be to queue people prior to entering that path.Your take on this is very appreciated. Thanks much, Steve.
saalon
I don't think you need to track arrival time .. you can actually track the moment of click to initiate the purchase process. Systems like Ticketek then set a hard limit on the time the ticket will be available from that point ... so once you start, you have X minutes to complete the transaction.
Toby Hede