Another year, another rush for tickets .Another year of getting hyped up for the main event of the year. The doom and gloom of winter and October brings the positively amazing ability to pay your £50 deposit (or pay outright) for you glasto ticket for the following year. What should be a smooth and faultless process (given it is 2010) has always been a complete sham – for as long as the responsibility of graceful execution of this process has lain at the foot of SeeTickets.com at least.
What about then, if we have too many people accepting the baggage and then we get a massive pile of un-handled baggage building up inside the depot - the same thing - we're stuffed. A pile of baggage is a pile of baggage. Whether it's on the front desk or behind the front desk. Well, luckilly we can pull the same trick - we can add mroe bagage processing machines and staff.
Now we're talking, we have redundancy so that when things are slow, we have 50% of our baggage handling machine sittinge idle, but when things go potty, we can ramp up to handle the traffic. But baggage handling machines are still expensive to run and maintain - and having laods of machines sat around doing nothing is wasteful.
What can we do now?
Well - how's about managing the capacity of throughput without havign to scale to unlimited potential. How can we do that?
Let's think about the problem at hand. What actually happens? The customers give the baggage to the checkin desk, the checkin desk does some minimal processing and hands that baggage to the baggage handlers who do all the magic and process the baggage. The customer doesn't need to wait until the baggage has reached its destination before moving on. They just want to go away in the knowledge that when time comes to get their baggage - it will just be there. Where they expect it. They get a little bit of paper that says - we've taken your baggage and we're going to do what you'd expect with it - don't you worry about a thing - go grab a beer and enjoy your flight. There's an agreement about the level of service and the expected outcome can be based upon this. Your baggage is added to a queue on a conveyor belt and processed in time.
Note: in software terms - the message queue isn't something an end user is even aware of. It simply (in the terms of a ticketing system) allows the system to take the info of how ever many people they have tickets for and then releases a page saying there are no more tickets. The users are oblivious to the queue. If the form which the user fills out is being hammered then the ticketing system should use a circuit breaker and release a static page with an explanation (described below).
In web terms this would mean that when you enter your credit card details - we don't need to take the payment right now, we just add your request to a queue and process it in time. That way if the application server that processes all of the payments gets bogged down, the front end that handles the website doesn't fail and die. In software this is called a message bus. Where as for my current project, the license for the IBM enterprise service bus cost in excess of £1,000,000 - there are (of course) very capable and very stable open source/free or at the very least very, very cheap offerings:
- nService bus (free)
- Rhino.ETL (free)
- MSMQ (free)
- AppFabric - part of windows azure cloud services (cheap)
- Amazon ESB (cheap)
- MassTransit (free)
Next up we have a thing called self monitoring systems. Sounds simple - and pretty much is. You code the system to monitor itself by creating requests to itself - if the processing time of any of those requests begins to lag beyond an acceptable threshold you create a cutoff and provide a static HTML page offering an appology, explanation and alternative action.
There's a million and one things we could do to make SeeTickets.com more effective when trying to deal with the annual wrath of Glasto fans. I've detailed some here which would turn their site into a more capable system over night and at no real extra cost. The devs just nee to use their loafs, remember why they got into software in the first place and pull their fingers out.
Finally - last year they were running ASP3 (a technology any respecting company wouldn't use out of choice for the last 10 years - in tech terms that's about a thousand human years) - I doubt that would have changed this year. It is susseptable to SQL injection attacks, probably old buffer overrun attacks and god only knows what else. It's not efficient, secure, reliable, scalable, robust, well designed or any of the features of a modern framework. It's not responsibleof SeeTickets.com, in the context of data integrity, user experience and in the context of the public image of glastonbury for them to continue to use such crap and unsuitable technology - especially when you consider sorting out the mess is free and is only a case of effort on their behalf.
Note: ASP3 is good for beginners starting out programming (in my opinion it isn't academic enough and could teach some anti patterns and bad habits, aside from the point that the newer .NET itteration is just as easy to learn but I accept the point). It's simple and quick to turn around. That doesn't mean it should be used in any large scale or high throughput systems. My point is that it's much, much harder to protect against huge security flaws such as SQL injection attacks. It's much, much harder to test so any guarantees a company gives to its client about stability can't be upheld. Any company that deals with a company who uses ASP3 would not be able to offer any sort of high end guarantee regarding service level agreements. There simply is no reason to use it.
If on the other hand - SeeTickets.com can't introduce these measures because they are commited to using their archaic code simply because they have invested so much time and effort into it and refuse to let that go - then I feel sorry for them. The monopoly won't always be such an easy one to take. When the new kid comes on the block and proves to be more agile, capable and willing to embrace more modern, industry standrard, efficient and scalable technology - they will not be able to keep up.
This advise is free. It's free because you can google most of these issues and the results will be instantaniously presented for free. Any n00b developer can provide this advice for free and the means to implement it are free. The system I'm working on right now is tested to handle a minimum of 2000 requests per second - these are complex queries too. This is on a 2 server set up. In the test environment.
We're busy creating a new site for our users. Rest assured we wont be suffering the same issues SeeTickets.com suffer (should it become as popular as we hope!) - and we do it on zero budget.I'll blog about that in a few days - we're gonna need a bit of help from our followers in terms of ideas and testing but we're proper buzzed about it - we hope you are too. It seems to us that websites in the feestival/music events space are making the whole thing look painful and are just there to rinse the money - that needs to change.