Ticketing is hard. It's like a lot of business solutions where a custom logic language is essentially baked in to describe price points, discounts, and more.
For example, Tixato (my current favorite free ticketing platform) tries to use "price groups". For each event, you set up a series of price groups that make a base price and discounts based on it. You can then assign specific price groups to each night. So for a $15 show with a $5 or maybe a 20% student discount, you just write it as such. But what if you want to offer a 2-for-1? Make a 50% price point, right? But what stops people from buying just one ticket at that point? Now you need to handle that case. And they just get crazier and crazier.
Plus, ticketing takes a heavy load. The I Heart Radio festival this year sold out in 8 minutes. The room has a capacity of 16,800. The festival is two days long. Let's assume only 28,000 were put on sale (the rest were for giveaways, house seats, artists, and artist comps), that's still 3,500 transactions per minute of $423 each (plus fees). You don't want that to screw up.
Fab. That's helpful. And getting all of that detail right strikes me as the kind of thing that is best approached through incremental growth, so that you can polish cases in collaboration with clients. Which, as you said, this market is not well suited for.
In this particular case, auto-scaling would be too slow, so you'd have to do something more clever. And ticketing obviously has strong consistency issues, so that removes another set of optimizations.
And of course, you'd still have to do all the load testing to make sure your chosen back end really performed correctly, which is a large fraction of the scaling work.
Comments
Ticketing is hard. It's like a lot of business solutions where a custom logic language is essentially baked in to describe price points, discounts, and more.
For example, Tixato (my current favorite free ticketing platform) tries to use "price groups". For each event, you set up a series of price groups that make a base price and discounts based on it. You can then assign specific price groups to each night. So for a $15 show with a $5 or maybe a 20% student discount, you just write it as such. But what if you want to offer a 2-for-1? Make a 50% price point, right? But what stops people from buying just one ticket at that point? Now you need to handle that case. And they just get crazier and crazier.
Plus, ticketing takes a heavy load. The I Heart Radio festival this year sold out in 8 minutes. The room has a capacity of 16,800. The festival is two days long. Let's assume only 28,000 were put on sale (the rest were for giveaways, house seats, artists, and artist comps), that's still 3,500 transactions per minute of $423 each (plus fees). You don't want that to screw up.
Fab. That's helpful. And getting all of that detail right strikes me as the kind of thing that is best approached through incremental growth, so that you can polish cases in collaboration with clients. Which, as you said, this market is not well suited for.
Maybe, but that shit isn't easy.
In this particular case, auto-scaling would be too slow, so you'd have to do something more clever. And ticketing obviously has strong consistency issues, so that removes another set of optimizations.
And of course, you'd still have to do all the load testing to make sure your chosen back end really performed correctly, which is a large fraction of the scaling work.