Oracle OpenWorld 2015 - Ticketmaster talks database complexity as it heads for MySQL Cloud

Profile picture for user ddpreez By Derek du Preez October 29, 2015
Ticketmaster began as a Microsoft shop, it's now using MySQL on premise and is headed for MySQL in the cloud. All with the aim of improving online customer experience.

If you’ve ever been to a music, sporting or theatre event, you’ve most likely heard of Live Nation - or rather, Ticketmaster, it’s online ticketing sales company. The company sells over one hundred million tickets globally each year, all online, to customers wanting to go to events, at venues in locations all over the world.

But, behind the company’s rather excellent online experience (I’m a regular user myself), lives a world of complexity. Particularly at the database level. Hari Tatrakal, Director Of Database Services at Live Nation/Ticketmaster, was presenting on the challenges that he faces in ensuring customers consistently get a smooth ticket buying experience at Oracle OpenWorld this week.

He also explained that Oracle’s MySQL database has been central to the company’s success in delivering a strong customer experience online.

Tatrakal began his presentation by saying that although every business is unique in its own way, its challenges are also unique. Given the scale of Ticketmaster’s operations, he said that his company’s challenges are not only unique, but they also “complex and big”.

For example, he said that selling X number of tickets for a venue, no matter how many tickets that may include, isn’t particularly challenging using today’s technologies. But when you consider that all those sales may happen in an incredibly limited timeframe, complexities begin to be introduced. He said:

I’ll give you a quick walk through how our online ticketing works. Let’s say a fan will go to Ticketmaster and then look for an artist and event and then narrow it down by day and then look for ticket availability, seating, and then look through until he finds the best ticket for the best price. If he decides to purchase he will click ‘buy’ and then put in all the information to complete the transaction. Looks pretty simple.

A little observation from the database side. Anything that the user enquires, they are all selects on the database. Everything you do, all the analysis before you click purchase, are all selects. So if you take on average for every transactions, let’s say there are five selects. If you look at a typical venue like Maddison Square Garden - it’s about 20,000 seats. If you have to sell everything at that venue, there will be about 100,000 selects to complete 20,000 transactions, on a rough scale.

It doesn’t really looking challenging, but what if everybody is trying to purchase in the same hour? That’s where complications start because everybody is trying to book the same ticket. There is concurrency, there are locking issues, there are resource issues - in every technology stack. That’s where Ticketmaster is different to any other online sales. This is a fringe case, but that’s exactly what we deal with in every sale.

It doesn’t end there. That’s just for one venue and one event. Tatrakal said that now imagine that that’s the case for thousands of venues and events all across the world, all needing purchasing at the same time. That’s the situation that Ticketmaster - and its databases - are in. He said:

20,000 tickets should not be an issue, even in one hour. But this is just talking one event in one venue. What if I expand that to all events in that venue? Just adding the rush factor for those 20,000 tickets, times the number of events in that venue. There is definitely some complexity depending on the on-sale timings and those things.

If I add the complexity of selling all tickets, in all venues, for all events, that’s what we have.

And that’s why Ticketmaster requires the best database architectures it can get access to. Tatrakal said:

Data has to be distributed, performance has to be good, the system has to be highly available, highly scalable, resilient and easily manageable.You have a farm of 500 databases, obviously the complexity grows if you can’t manage it properly. This complexity is what makes us different from everyone else.

Past, present and future

Tatrakal explained that as Ticketmaster was growing back in the early 2000s, it had traditionally been a Microsoft house, right throughout its technology stack. However, as the site’s popularity started to grow and buyer’s behaviours started to shift from box-office sales to online, this forced the company to reconsider its options. He said:

Ticketmaster was a complete Microsoft shop when we started. At the time our usage was only 20%, 80% was all in the box office. In early 2000 there was a growth in popularity in online sales and our demand exceeded that capacity of what we had.

We had issues with the website not responding, especially on peak hours. Data was not consistent. So we had a tough time to manage everything. Our design was not scaled enough, not beefed up to support the transactions of the search, as well as the architecture of the technology stack.

As a result, Ticketmaster decided to move to Oracle MySQL in 2002, following an evaluation of the company’s architecture. Tatrakal said that since making the move, it has brought a number of benefits to the company - namely scalability, performance, cost and usability. He said:

Our major problem was that we were not able to elastically expand and cater the requirements when we grew from 20% of sales to the 80% of sales that we support today. MySQL has one package, one configuration type to worry about. It’s very easy to spin up an environment and stand up MySQL, copy the data, sync it up and make it available. Using that we could elastically expand to the requirements of our business.

Performance [was also key]- replication is one of the best strengths of MySQL and it proved that again and again with our online sales. The magic behind that is all replication. We never have any issues and it’s probably one of the key successes of our online sales.

We also have DBAs supporting the MySQL environment from a non-DBA background and they are able to pick-up and work very fast, just because of how nimble and easy it is to manage.

However, despite the success that Ticketmaster has had with MySQL on premise, the company is now

planning to make the move to the public cloud this year. Why? Speed. Tatrakal said:

2015, this year, the very exciting thing is that we are going public cloud. It’s still in the rudimentary phases, but we are very excited. MySQL is probably one of the most friendliest databases to be in the cloud because of how nimble and agile it is. It is easy to put in the cloud.

The major difference between a cloud and a traditional warehouse, is if you want to spin up a new environment in a traditional data centre - it’s a bit of an effort. You have to go through the whole nine yards. If it’s in cloud, everything can be spun up quickly.

News to Oracle’s ears, I’m sure.