Skip to main content

​
The Smart Waitlist Engine

Managing sold-out events is typically a nightmare for organizers. Students beg for tickets, attendees no-show, and manual transfers lead to fraud. UniTix solves this entirely through backend automation.

​
The Trigger: Reaching Capacity

When a Society Admin creates an event, they define a capacity (e.g., 500 tickets). Every time a ticket is purchased, a Firebase Transaction atomically increments the ticketsSold counter. When ticketsSold === capacity, the frontend automatically locks ticket sales and swaps the primary CTA button to “Join Waitlist”.

​
The Queue

Students who join the waitlist are stored in a Firestore subcollection: events/{eventId}/waitlist/{userId} They are ordered strictly by the joinedAt server timestamp.

​
The Reallocation Flow

The magic happens when an existing ticket holder realizes they can’t attend and clicks Cancel Ticket.
  1. Transaction Begins: The backend runs an atomic Firebase transaction.
  2. Decrement Counter: The ticketsSold drops from 500 to 499.
  3. Fetch Next in Line: The backend queries the waitlist subcollection for the oldest entry.
  4. Grant Reservation: The backend moves that user from the waitlist into a special ticketReservations array on the event document.
  5. Email Notification: The student is automatically emailed: “A spot opened up! You have 24 hours to claim it.”

​
The 24-Hour Cron Job

What happens if the student misses the email? We cannot let that ticket sit empty forever. UniTix utilizes a scheduled Cron Job (/api/cron/cleanup-waitlist) that runs every single hour.
  • It scans all events globally.
  • It checks the reservedAt timestamp of every user in the ticketReservations array.
  • If reservedAt is older than 24 hours, the cron job violently deletes their reservation.
  • It immediately grants the reservation to the next person on the waitlist.
This ensures that tickets are always flowing to students who actively want them!