Distributed Ticket Sales System

Running the ticket sales system for Playa del Fuego has presented some peculiar challenges I don’t face in most products. Primarily, there’s the issue of dealing with a thousand or more simultaneous users during opening sales but very little traffic over the rest of the year.

We tried outsourcing to a third-party vendor, but their servers crashed and burned even worse than ours. They claim to have grown since then, but then again so have we. I thought I’d found the answer with Dreamhost’s virtual private servers, but they don’t quite live up to their promise (I had the setting maxed out and the usage graphs showed nothing unusual, but pages were still timing out).

Next time, I’m going to have to get out the big guns: Amazon’s Elastic Compute Cloud and Simple Queue Service. The idea is that, before a user is allowed into our ticket system, they’ll have to sit in a queue and wait their turn.

The queue will be a simple script running on the EC2 service that stacks everybody up in SQS. When a user is ready to be passed on, they’ll be marked as such in SQS then passed over to the ticket system. The ticket system then has to simply check SQS and verify that they’re approved for entry, and they can then proceed to go through with the purchase.

The queue can either be updated by the ticket system whenever an order is completed or times out (allowing N number of simultaneous purchasers), or simply by acting on a timer (allowing 1 additional purchaser per N seconds), or even more sophisticated means (CPU and memory monitors dropping below a certain threshold).

There’s a pretty good primer on using python and EC2 here.