QueuePass

Inspiration

We really love music, and we know how stressful it is trying to buy concert tickets for artists like Taylor Swift or BTS. Every time tickets drop, the same thing happens. The website freezes, crashes, or kicks you out. It feels chaotic and unfair, and sometimes bots grab everything before real fans even get a chance.

We started thinking about what is actually happening behind the scenes when that many people hit a server at once. That is where QueuePass came from. Instead of letting servers crash, why not control traffic in a clean and fair way?

We were also inspired by the fact that at UIC, we do not really get deep exposure to building APIs from scratch. We learn theory, data structures, and algorithms, but not always how to design infrastructure that real systems rely on. We wanted to challenge ourselves to build something more “backend heavy” and understand how APIs actually work in the real world.

What it does

QueuePass is a virtual waiting room API.

When too many users try to access a resource at the same time, such as concert tickets or course registration, they are placed in a structured queue instead of overwhelming the server.

The API: Creates events (like a ticket drop), Issues unique tickets to users, tracks their position in line, Estimates wait time, and allows admins to admit users in batches when capacity is available. It is infrastructure-focused. There is no frontend. Other applications can plug into QueuePass to manage traffic safely and fairly.

How we built it

We built QueuePass using FastAPI because it is lightweight, async, and automatically generates interactive documentation. That helped us focus on API design and correctness instead of UI.

We used Pydantic for strict input validation and collections.deque for efficient in-memory queue operations to manage state during the hackathon. We designed the system around clear resources like events and tickets. We made joins idempotent so users cannot accidentally get multiple spots in line if their request retries. We also implemented proper HTTP status codes to make the API predictable and developer-friendly.

Challenges we ran into

Since this is a queue system, everything depends on being consistent ordering. We had to think carefully about edge cases like: What happens if a user joins twice? What happens if an event closes while people are still waiting? What if the admin tries to admit more users than are in the queue?

Accomplishments that we're proud of:

We are proud that QueuePass is not something simple, but it actually models a real infrastructure problem.

We are proud that: • Our join endpoint is idempotent • We use the correct data structure for a queue • We return proper HTTP status codes • Our API is clean and testable through curl or Postman • The documentation is clear and usable

Most importantly, we are proud that we built something that feels like real backend infrastructure, not just a demo app.

What we learned

Before this hackathon, we honestly did not really know what an API was. It just felt like a buzzword people in tech throw around all the time. We would hear “build an API” or “use their API,” but we never actually understood what that meant in practice.

Building QueuePass forced us to actually learn what an API is. It is not just endpoints. It defines clear rules for how systems talk to each other. It is about structure, predictability, and handling edge cases properly.

What's next for QueuePass

Next, we would like to improve security and make the system handle traffic across multiple servers. We would also explore real-time updates instead of polling and stronger bot protection. Long term, we see QueuePass becoming an infrastructure that platforms could plug into whenever they expect high traffic. The goal would be to make large-scale releases feel more controlled and fair, instead of chaotic and overwhelming.

Built With

• fastapi
• mailjet
• pydantic-v2
• python
• uvicorn