Ideas from the team

Category

Building a Ticketing System from the Ground Up

Stuart guides us through various ticketing options and the thought process behind building a ticketing system such as Spektrix.

Ever wonder what goes on in the background of your ticketing system? Turns out it’s not as simple as you might think! Starting from the very basics with just one person sat in a box office selling, through to having many transactions going on at once, there’s a lot to think about.

One of our senior software engineers, Stuart, guides us through various ticketing options and the thought process of building a ticketing system such as Spektrix.

The basics

Once upon a time, there was a ticketing world without computers. Let’s imagine for a moment, we live in that world now and we wanted to create a brand new ticketing system. How would we do it?

To start with, let’s think about the basic rules that make a good ticketing system:

  • Two people can't sit in the same seat
  • You can return seats - that seat can now be sold again
  • You want to let customers select their own seats
  • You don't want to tell customers a show is full if there are seats available

Option 1: Going solo in the box office

Our first ticketing system option is one person sitting at a desk in a box office, with a copy of the seating plan for each show. They cross seats off when they sell them, and take the customer's money and write out the tickets. So far, so good, but it's slow.

A way to speed this up is to have more than one person in the box office. You split up the events, and have one person for each event. Now you can handle more customers, but you start to have problems if the customer wants to buy more than one event at a time. They would need to queue for each one separately and you might also end up with a big queue for one seller when there’s one very popular event.

You could split an event so that each show performance has its own ticket seller, but then it would be difficult for each seller to answer questions such as “which day next week will get me a seat furthest forward?”

Option 2: Allocating tickets to more than one staff member

How about a different tactic?

Instead you take our ticket sellers and give each of them an allocation of seats for each performance, and they can work independently. You start to have issues once one of the ticket sellers has run out of seats for each performance and doesn't know if the others have any left. They can telephone each other every so often to rebalance, but you still may end up turning people away incorrectly. Remember, you don’t want to turn customers away if there are still tickets to sell!

You can also only scale it so far before you run out of tickets. Suppose you have 100 tickets at a certain price band, and 10 people selling them. That's 10 tickets each, and it doesn't take much for one to run out. If a customer wants to get a particular seat (e.g. extra legroom or level access) they need to hope they happen to speak to the person with the right seat. This way of dividing up allocations, however, is the way a lot of agency sales still work, and they do this very effectively. But there are still improvements to be made.

Option 3: Creating a database

How about you have one person in the middle, let's call him DB, with a stack of seating plans, and he’s surrounded by box office staff who deal with the customers. When the customer asks for a particular event performance, the box office staff speak to DB and he will give them the performance seating plan. The customers select their seats, the box office staff cross them off on the plan, and hand it back to DB. This works well as customers spend a lot of time at the desk when they aren't actually selecting tickets (e.g. when they’re paying) so you can serve more people quicker than before, while still offering all the seats to all the customers.

Well, almost. If a customer selects seats, then changes their mind before paying, you might tell another customer that they're sold (or even that we're sold out) when that's not actually the case, but without this customers are having to queue too long and heading to the cinema down the road instead, so it's not a bad compromise to make.

Option 4: Dealing with popular and busy shows

All is well, until you have one show that everyone wants to see, and you realise that everyone is waiting on the same plan.

That’s where a new idea comes into play. DB can keep the original plan, and just hand a copy of the plan to the box office staff. Now you can show the same plan to several people at the same time. The customers select the seats they want, and the box office staff ask DB to mark them on the plan as sold. If it so happens that another customer has selected the same seats, they'll be told "sorry, pick again" and shown a new copy of the plan.

Incidentally, if you try this on Spektrix and you have best available seating set up, instead of being told to pick again the customer gets automatically offered the best available seats in the same price and seating area.

Occasionally customers will be told "sorry, choose again" but you allow far more people to go through the box office at the same time, so we can cope with the busiest of periods.

Option 5: Building a complex ticketing system

It’s pretty much how Spektrix works. The "box office staff" are our web servers, and DB is our database cluster. But in actual fact, what we describe above happens twice.

Firstly when a customer goes to your website, we send them a copy of your plan, but other customers can still buy tickets on it in the meantime, and when a customer makes their selection we check the seats are still available, and tell them "sorry, pick again" if they aren’t.

But it can also happen if two customers happen to click at the exact same time. When those clicks reach our web servers, it takes time for us to act on them and send them an updated website. It's not long, certainly less than a second, but that's an eternity to a computer. It might happen that both clicks reach our web servers at the same time, and we start processing them at the same time, meaning both see the seats as free. We go through the process of marking the seats as selected, working out the ticket price and then try to save them back to them database. One of them will be quicker, and that one gets the seats. The other customer gets a message saying "sorry, those seats are no longer available".

It's the same process as above, but happening in a fraction of a second, and the customer will never know it happened. This is known as optimistic locking. We are optimistic that no one else will select the exact same seats, so we proceed as if no one does. But we do this in such a way that we can back out if someone has selected them and no harm is done. The alternative, where only one web server can look at each seating plan at the same time, is pessimistic locking. Spektrix used to use pessimistic locking, but we moved to Optimistic Locking a few years ago to manage big onsales. We are always looking for extra tricks like this to help us cope with high demand.

 

The logic of ticketing systems is pretty simple. But as we can see, going from one person in a box office to being able to sell thousands of tickets at once is a big challenge. While all of this seems complicated, luckily a computer, and in our case Spektrix, does this whole process in a matter of seconds so you don’t have to think too hard about the process!