Building a high-performance ticketing system with TigerBeetle
1–10 of 47 posts
Re: Building a high-performance ticketing system with TigerBeetle
#2Selling an event out takes a long time to do frequently because tickets are VERY frequently not purchased--they're just reserved and then they fall back into open seating. This is done by true fans, but also frequently by bots run by professional brokers or amateur resellers. And Cloudflare and every other state of the art bot detection platform doesn't detect them. Hell, some of the bots are built on Cloudflare workers themselves in my experience...
So whatever velocity you achieve in the lab--in the real world you'll do a fraction of it when it comes to actual purchases. That depends upon the event really. Events that fly under the radar may get you a higher actual conversion rate.
Also, an act like Oasis is going to have a lot of reserved seating. Running through algorithms to find contiguous seats is going to be tougher than this example and it's difficult to parallelize if you're truly giving the next person in the queue the actual best seats remaining.
There are many other business rules that accrue after years of features to win Oasis like business unfortunately that will result in more DB calls and add contention.
Re: Building a high-performance ticketing system with TigerBeetle
#3Having built a ticketing system that sold some Oasis level concerts there's a few misconceptions here: Selling an event out takes a long time to do frequently because tickets are VERY frequently not purchased--they're just reserved and then they fall back into open seating. This is done by true fans, but also frequently by bots run by professional brokers or amateur resellers. And Cloudflare and every other state of…
Re: Building a high-performance ticketing system with TigerBeetle
#4Re: Building a high-performance ticketing system with TigerBeetle
#5Edit: Yes, I think I misunderstood something here. The user wouldn't even see their request as having returned a valid "pending" ticket sale since the batcher would be active as the request is active. The request won't return until its own transfer had been sent off to TigerBeetle as pending.
Re: Building a high-performance ticketing system with TigerBeetle
#6Having built a ticketing system that sold some Oasis level concerts there's a few misconceptions here: Selling an event out takes a long time to do frequently because tickets are VERY frequently not purchased--they're just reserved and then they fall back into open seating. This is done by true fans, but also frequently by bots run by professional brokers or amateur resellers. And Cloudflare and every other state of…
Re: Building a high-performance ticketing system with TigerBeetle
#7Is FastAPI just bad with SQLite? I would have expected SQLite to smoke Postgres in terms of ops/s.
Re: Building a high-performance ticketing system with TigerBeetle
#8Is FastAPI just bad with SQLite? I would have expected SQLite to smoke Postgres in terms of ops/s.
SQLite is in process, but concurrent write / performance is a complex matter : https://sqlite.org/wal.html
Re: Building a high-performance ticketing system with TigerBeetle
#9Having built a ticketing system that sold some Oasis level concerts there's a few misconceptions here: Selling an event out takes a long time to do frequently because tickets are VERY frequently not purchased--they're just reserved and then they fall back into open seating. This is done by true fans, but also frequently by bots run by professional brokers or amateur resellers. And Cloudflare and every other state of…
Does that mean that there is some smoke and mirrors when, eg Taylor Swift, says they sold out the concert in minutes? Or are the mega acts truly that high demand?
Re: Building a high-performance ticketing system with TigerBeetle
#10Is FastAPI just bad with SQLite? I would have expected SQLite to smoke Postgres in terms of ops/s.