I am not sure if I am posting in the right secion.
In Brazil, there is a large ticket sales company called Ingresse. I recently found out that they use Elixir. There’s another company called Ticket Sports, which focuses more on selling tickets for sports activities like races, triathlons, etc. Recently, Ticket Sports became responsible for selling tickets for Brazil’s largest race, São Silvestre. People trying to buy tickets encountered many problems. I don’t know if Ticket Sports uses Elixir, but I think they don’t. Ingresse recently bought Ticket Sports. Whether they’ll migrate to Elixir or not, I can’t say. But my question is, these problems are usually reported on ticket sales platforms—I’ve heard about them happening to various companies. Is there any company that happens to use Elixir or Erlang and is known for not having these kinds of problems? For example, a million people try to buy tickets for a Taylor Swift concert at the same time, and the system holds up? Does anyone know?
Ironically, one of my current clients is in the business of auctions of tickets to ticket brokers… but… they aren’t on Elixir and they don’t see large transactional volumes quite the way you’d see it in direct box office sales.
I would have to think that Elixir and the BEAM would be excellent choices for the problem. Assuming a good architecture, I could see the overall concurrency and process isolation features of the BEAM allowing for superior solutions for this kind of problem compared to other stacks. Indeed, my expectation would be the most sensitive part of the system, operationally speaking, would be the data/database handling on the backend.
(adding because I didn’t explain why I think what I think)
If we think about the original problems the BEAM was designed to deal with… lots of individual sessions (phone calls) running in parallel with mandates to not allow problems in any one of those sessions to derail the system or disrupt the other sessions… I see exactly the kinds of traits I would want in a consumer sales system: each consumer’s session is not completely unlike a phone call… and I wouldn’t want any one session to take down the system or interfere with the other consumer’s also engaged in sessions. Yes, these are computationally more expensive/involved than a phone call might be… the mechanism in the BEAM would still apply. I have to think building these kinds of resilient, performant systems on the BEAM are simpler to get right as compared to other tech stacks.
I’m not saying this is the most ideal solution out there and it’s not exactly what you’re asking, but it seems to work well AFAICT: I’ve seen some ticket sales platforms use a pooling system, where N users gets Y minutes each to complete the transaction. Other users get in a queue to purchase the ticket and can see their place in line and estimated time remaining.
When the pool queue is not full (after demand stopped peaking), users just have a regular experience of buying anything online (with the same timer of Y minutes to complete checkout - in case it peaks again - but they don’t usually have to wait to buy the ticket).
To be fair I don’t know what technology those platforms were built with, but that type of system seems relatively simple to build with Elixir / BEAM + Phoenix Channels (a lot easier than other technologies IMO), and I think it can help smooth out peaky loads during high demand. I’d be more concerned about the database, much more so than the servers which you can scale horizontally fairly well.
There was someone here in the forum that built an app to handle student sign ups in Germany iirc. They had this precise use case in mind. I’ll try to search for a little bit on it.
Anecdotally, we just had an experience with a system that failed at this exact issue . The parents eventually figured out that if you created a NEW account and tried to register your kid for the activities (what had a set time to start taking registrations) it would work, while folks with existing accounts would not. Parents figured out that it was worth doing this duplication. The kids got registered as expected, and, the parents then opened requests to get the accounts merged. The first one that got their account merged had the account get borked, so… they are having fun with this
Taylor Swift came to Brazil last year.
Their team hired a company called Tickets for Fun. I translated part of a news story below.
I was one of those people that tried to buy a ticket but didn’t get it.
Here’s how it went. You clicked a link before the ticket sales started and waited. At 10 AM, a lottery took place, and you were given a number. In other words, the more devices you had connected, the better your chances were.
Then you had a number (for example, 1,456,778), and the screen showed where the sales were in the queue. The queue number kept going down. Problem: when it was my turn, the tickets were already sold out, but I had to keep waiting until my turn came up.
After the rapid sellout of tickets for Taylor Swift’s concert in Brazil, thousands of complaints were made against Time For Fun (SHOW3), the company responsible for the Tickets For Fun platform, leading to a notification from Procon and even a request for investigation by the Public Prosecutor’s Office (MP).
Around half an hour after ticket sales opened for Taylor Swift’s concert, the tickets were already sold out, by approximately 10:30 AM last Monday (12th). It is estimated that over 1.7 million people were waiting for the start of sales.
Many fans of the singer claimed that the platform was overtaken by scalpers, who, after acquiring the tickets, were already selling them on non-official platforms. Some of these complaints against Time For Fun (T4F) were registered on Reclame Aqui.
. The parents eventually figured out that if you created a NEW account and tried to register your kid for the activities (what had a set time to start taking registrations) it would work, while folks with existing accounts would not. Parents figured out that it was worth doing this duplication. The kids got registered as expected, and, the parents then opened requests to get the accounts merged. The first one that got their account merged had the account get borked, so… they are having fun with this 
