Scalable Booking Backend - Handling 10 000+ Concurrent Users

[ZynthCode]

Hello everyone!

I want to share some thoughts on a ticket booking backend solution I am working on, as it may be relevant to what we wish to build here.

My goal is to initially replace Furway’s existing ticket sale service with something that can comfortably handle at least 1,000 concurrent users at the “buy ticket” stage right from the start, and eventually scale to 10,000+ users. This is a commitment I’m planning to see through regardless, but if it turns out our visions overlap, I’d love to explore how this could benefit everyone else.
I’ll also be open about hoping to commercialize it so I can support both myself and non-profit organizations full-time, since I am working/volunteering probably more than 200%, and have some health issues..

Key Goals

1. ✅ Instant feedback: No uncertainty when booking. The moment you press the button, you know you have your ticket. No rushing to fill in names, emails, or other details upfront. One button per ticket. Just one.
2. ✅ Focused ticket reservations: Avoiding overcomplicated flows that mix in hotels, merch, extras, and donations.
3. ✅ Scalability-first architecture: Designed to handle extreme traffic spikes efficiently, with a goal of supporting 10,000+ concurrent users. It also help to scale preemptively when we know the time it is going to be intense. As far as I know, no other booking solution has that feature.
4. ✅ Waiting list system: Ensuring that if a ticket is canceled, the next person in line is given the opportunity to claim it. If conventions want to add flexibility on top of this, then that would be a separate system on top of the backend.

Why?

Most convention booking systems today are unnecessarily complex, turning what should be a simple process into a frustrating ordeal. My vision is to build a backend that prioritizes speed, simplicity, and reliability, ensuring that booking a ticket feels as effortless as pressing a button and receiving instant confirmation.

No one should have to spend 2-5 hours waiting. Even 30 minutes is excessive. Ideally, the entire process should take no more than five minutes. If manual user validation is necessary, it can be handled after booking rather than becoming a bottleneck. Instead of requiring immediate payment, consider enforcing a one-week period for validation and approvals. That way, your con's unique processes can run in the background without slowing down registrations. But I digress...

If we can align on this vision, I think it could be a great addition to what we are building. Regardless, I am committed to making it happen and would love to hear your thoughts on how we can make it even better!

Looking forward to your feedback! 😊

[RustyBraze]

You have good ideas and please allow me to make a few comments.

About Point 1:
The "uncertainty" or delay getting the ticket or confirmation is done on purpose. This is usually not an issue with the backend or the software, because there are validations that are required to run or be manually confirmed based on internal workflows/policies. Some cons even allow the attendee to register at any time of the year, so the ticket ordering is literally like you describe, just one click order.

Also, some countries have laws that you are not allowed to tell the person that you have the ticket for the event and later cancel (event side). In some/most cases, the person is legally entitled for compensation that can extend the cost of the ticket.

For example, the person booked the hotel at the moment they get the ticket confirmation and after a few hours/days the system/staff flags an issue/reason and have to cancel.

Even if the person did not pay for the event, the event may be liable to pay the costs of the hotel cancellation. (if the person paid already the ticket, it makes another huge wave of issues and complications - some payment providers charge you to cancel the payment of your customer...)

Not only is it bad for the person that bought the ticket, but this can even damage the reputation of the event.

About Point 2:
The flows are needed. Small cons may only have a ticket sale but large cons, you offer packages and combinations to the attendees. Some cons allow the attendees to book/add more stuff to their ticket, for example, get a ticket today and one month later, add a t-shirt or boat party or something else. And yes... some packages may have different deadlines, different workflows and even a limit of positions/goodies.

Keep in mind, staff usually use the same system for registration and in some cases, a different workflow may be required to handle this and have different packages attached.

Please, don't take my comments as a way of criticism, I just wanted to share some light of why some systems or cons seem to have unnecessary complexity.
Every system can be simplified and optimized, but the level of simplification or optimization drastically depends in several factors, including local applicable law. :)

[ZynthCode]

You have good ideas and please allow me to make a few comments.

About Point 1: The "uncertainty" or delay getting the ticket or confirmation is done on purpose. This is usually not an issue with the backend or the software, because there are validations that are required to run or be manually confirmed based on internal workflows/policies. Some cons even allow the attendee to register at any time of the year, so the ticket ordering is literally like you describe, just one click order.

Also, some countries have laws that you are not allowed to tell the person that you have the ticket for the event and later cancel (event side). In some/most cases, the person is legally entitled for compensation that can extend the cost of the ticket.

For example, the person booked the hotel at the moment they get the ticket confirmation and after a few hours/days the system/staff flags an issue/reason and have to cancel.

Even if the person did not pay for the event, the event may be liable to pay the costs of the hotel cancellation. (if the person paid already the ticket, it makes another huge wave of issues and complications - some payment providers charge you to cancel the payment of your customer...)

Not only is it bad for the person that bought the ticket, but this can even damage the reputation of the event.

About Point 2: The flows are needed. Small cons may only have a ticket sale but large cons, you offer packages and combinations to the attendees. Some cons allow the attendees to book/add more stuff to their ticket, for example, get a ticket today and one month later, add a t-shirt or boat party or something else. And yes... some packages may have different deadlines, different workflows and even a limit of positions/goodies.

Keep in mind, staff usually use the same system for registration and in some cases, a different workflow may be required to handle this and have different packages attached.

Please, don't take my comments as a way of criticism, I just wanted to share some light of why some systems or cons seem to have unnecessary complexity. Every system can be simplified and optimized, but the level of simplification or optimization drastically depends in several factors, including local applicable law. :)

Thanks for the fantastic feedback! I appreciate you shedding light on some of the nuances and potential complexities some cons have on top of it all, not to mention the potential legal considerations.
As a small con, we are lucky to avoid some of the hassle that larger cons deal with, but I would love to hear more about these challenges and figure out whether they can be addressed as part of this streamlined approach!

Regarding instant ticket confirmation, I completely understand that some conventions require pre-validation steps before confirming a ticket. My approach does not remove that option; it just ensures that where instant booking is possible, it happens without delay. If manual validation is needed, it can still take place after the initial booking rather than creating uncertainty at the moment of purchase. That way, ticket sales do not turn into a stressful rush where most attendees are stuck waiting for an unknown outcome. I am tempted to name some (American) cons, but I shall not since I do realize they are doing their best with what they have 🫶

On complexity in flows, I fully acknowledge that larger cons may have additional needs like bundling hotels, merch, or add-ons. My focus is on keeping the core ticket booking as simple and scalable as possible. If conventions want to integrate additional workflows, that should be a separate layer they can build on top, rather than something forced into the base system. The goal is not to remove flexibility, but to ensure that for those who just want a ticket, the process is as fast and frictionless as possible.

Ultimately, I am looking to create a highly scalable and reliable backend that conventions can build on according to their specific needs. If we can align on that vision, I would love to spar more ideas and explore how this can benefit everyone. ⭐

[pivstone]

First of all, Scalable Booking Backend is a reasonable requirement for big con.
Let me give you some my thoughts,

we need to understand the term Scalable. Usually, when we say Scalable it means when we have 10 times traffic, our API server can auto scale up 100 times to handle those 100 times traffic. when we have low traffic, API server can scale down to save cost.

this is Scalable in DevOps and backend guys eyes.
The second part is how much are we scale up?

• 100 - 10000 times traffic only happens during the sales events (just few hours)
• 1-10 times during the con
• closed to 0 traffic after con

When the scale is 100+ times, we will hit infra limitation:

• Database (especially SQL) can't not auto-scale in this way (there is other databases can do such scale up/down).
• 3rd API (rate limiting) can't scale up
• Hotel ERP system limit

If we are aiming: Scalability-first architecture for 1K times traffic, we can pick up a database can scale up, but we can't pick a hotel ERP system.

Instead of Scalability-first architecture, I would recommend to build an efficient architecture. The metric should be (just example): 8 GB memory, 4 Core CPU Backend service can handle 20 transactions per second.

of course, I do have a full auto-scale solution from API to database, for example: AWS Lambda + DynamoDB. For my experience, we handled 5K times traffic spike in until we hit account level burst limit or dynamodb 5K request per second in a shard. But I would not recommend to go with this vendor full lock-in solution as a community solution. There is also open source solution like this, but. the maturity isn't there, and infra setup complicity is very high. Also the developer develop pattern is totally different, many developers don't like those nano function service pattern.

---

About Instant feedback

This one is clearly against common backend practices, in order to let backend service can handle more parallel requests, we intent do using cache, writing queue, asynchronous request and eventually consistent pattern to flat the curve (as covid). Due to those middleware, backend have to give up the Instant accurate feedback.

Because Instant feedback means user can query/ask our Database direct to get the realtime number, which is common design pattern want to avoid (reduce the Database Query number). Again, because database is something no so easy to scale.

---

About Waiting list system

That's a common solution as well, but not after buying ticket but before it. It's call Queue System. It's commonly to be see in big pop star selling ticket events. Usually you will see you are in Queue, you need to wait 43 mins to get into our system Blablabla.
This kinda Queuing system can be a plugin to enable in front of our backend service.

after all, I suggest to have a queuing system as "plugin" system to protect high traffic when it comes to drop. If the con don't have such high traffic, they don't have to install this plugin and prepare extra machines for those plugins.

for big con, then can just setup the queue system before the selling event, then remove related resources afterward.

[ZynthCode]

First of all, Scalable Booking Backend is a reasonable requirement for big con. Let me give you some my thoughts,

we need to understand the term Scalable. Usually, when we say Scalable it means when we have 10 times traffic, our API server can auto scale up 100 times to handle those 100 times traffic. when we have low traffic, API server can scale down to save cost.

this is Scalable in DevOps and backend guys eyes. The second part is how much are we scale up?

• 100 - 10000 times traffic only happens during the sales events (just few hours)
• 1-10 times during the con
• closed to 0 traffic after con

When the scale is 100+ times, we will hit infra limitation:

• Database (especially SQL) can't not auto-scale in this way (there is other databases can do such scale up/down).
• 3rd API (rate limiting) can't scale up
• Hotel ERP system limit

If we are aiming: Scalability-first architecture for 1K times traffic, we can pick up a database can scale up, but we can't pick a hotel ERP system.

Instead of Scalability-first architecture, I would recommend to build an efficient architecture. The metric should be (just example): 8 GB memory, 4 Core CPU Backend service can handle 20 transactions per second.

of course, I do have a full auto-scale solution from API to database, for example: AWS Lambda + DynamoDB. For my experience, we handled 5K times traffic spike in until we hit account level burst limit or dynamodb 5K request per second in a shard. But I would not recommend to go with this vendor full lock-in solution as a community solution. There is also open source solution like this, but. the maturity isn't there, and infra setup complicity is very high. Also the developer develop pattern is totally different, many developers don't like those nano function service pattern.

About Instant feedback

This one is clearly against common backend practices, in order to let backend service can handle more parallel requests, we intent do using cache, writing queue, asynchronous request and eventually consistent pattern to flat the curve (as covid). Due to those middleware, backend have to give up the Instant accurate feedback.

Because Instant feedback means user can query/ask our Database direct to get the realtime number, which is common design pattern want to avoid (reduce the Database Query number). Again, because database is something no so easy to scale.

About Waiting list system

That's a common solution as well, but not after buying ticket but before it. It's call Queue System. It's commonly to be see in big pop star selling ticket events. Usually you will see you are in Queue, you need to wait 43 mins to get into our system Blablabla. This kinda Queuing system can be a plugin to enable in front of our backend service.

after all, I suggest to have a queuing system as "plugin" system to protect high traffic when it comes to drop. If the con don't have such high traffic, they don't have to install this plugin and prepare extra machines for those plugins.

for big con, then can just setup the queue system before the selling event, then remove related resources afterward.

Thank you for sharing such detailed technical insights. Your experience with scalable systems, auto-scaling databases, and queue-based solutions is valuable, and I agree that these considerations are vital once we decide exactly how to implement things.

What I would love to clarify is that, so far, my main intention has been to focus on the higher-level business requirements and user experience goals. My idea of "Scalability-first" is rooted in the user perspective: if 10,000 people rush to buy tickets the moment sales open, I want them to have a near-instant confirmation that they’ve secured their spot, rather than waiting in a long queue or being uncertain for hours. That’s the essence of “instant feedback.” It might be one or two seconds of waiting while the spinner goes, but definitely not minutes or hours.

I haven’t yet delved into the specific technical route - whether that’s a queue system, a specialized database, or a fully managed vendor solution, partly because I prefer to establish the core needs first:

• A minimal waiting process when tickets go on sale, so attendees aren’t frantic or stuck refreshing pages.
• The ability to handle sudden bursts of traffic without locking or timing out countless users.
• A straightforward path to claim a spot so users are confident they’ve reserved a ticket right away (and can fill in extra details afterward, without the pressure).
• Not having to waste hours of their valuable time.

Naturally, the details of how to achieve that, like choosing a database that scales up or deciding whether to implement a front-end queue plugin - are def critical, and your points about how auto-scaling can hit limitations (whether it is a database bottleneck or a third-party API) are spot on.. Once we settle on these core requirements, we can absolutely explore solutions, whether it is an open-source approach, something vendor-specific, or a combination thereof. I have ideas of my own in how we can do this, but I have omitted those details for now. We also need to remain mindful of local legal requirements and the challenges that come with allowing “instant” ticket confirmations as RustyBraze commented. I certainly don't know enough about this myself... 😅

I also appreciate your comments about a queue system. Queuing can definitely protect against overwhelming surges and might be a perfect fit for particularly massive events. That said, our ultimate dream is a system so efficient it barely needs a visible queue. It might still be there in the background, but ideally so quick and invisible that users feel they’re getting immediate feedback. No stress, no guesswork, and no multi-hour waits.
That said, I can see a queue helping those who’ve already reserved a ticket spot by giving them a short wait time while finalizing their purchase. They’d know their spot is secure and simply wait those few moments for the next step in the process.

So yes, you’re absolutely correct to caution us about potential implementation pitfalls. I just wanted to emphasize that, at this stage, the conversation was about our end goals and the "business" vision: near-instant reservation confirmation, worry-free user experience, and enough flexibility to accommodate everything from small gatherings to huge cons.
Once we’re aligned on these core objectives, we can hammer out exactly which tools and approaches will serve us best 🔥 🔨

Thank you again for your thoughtful insights! I’m looking forward to learning more from your experiences as we refine both the "what" and, eventually, the "how", From what you’ve shared, it is clear you bring a wealth of knowledge to this discussion, and that’s fantastic! 🐈 ❤️