Event Ticketing Platform

Event ticketing is one of those domains where the complexity hides behind a deceptively simple interface. A user picks a seat, pays, and gets a ticket. Behind that flow sits a seat reservation system that must handle concurrent buyers, a payment pipeline that must survive provider failures, a validation system that works at the door on the night of the event, and management surfaces for at least four distinct stakeholder types — each with different data access, different workflows, and different concerns. Building all of this as a single coherent product is the challenge this project addresses.

Six Distinct Panels

The application is structured around six route groups, each representing a different context and access level.

The public frontend handles event discovery — browsing by category, city, artist, and venue — along with event detail pages, session listings, ticket purchase initiation, and a blog. The admin panel provides platform-level management across all entities: events, sessions, venues, artists, users, orders, cities, countries, and settings. The venue panel gives venue operators access to their own orders, session schedules, staff management, and a ticket validator. The artist panel mirrors this for performers — session visibility, order tracking, team management, and their own validator. The marketing panel is scoped to content operations: blog categories, posts, and newsletter subscriptions. The gateway is the checkout flow itself — a dedicated, isolated route group that handles the entire ticket purchase process from seat selection to payment confirmation.

The Checkout Gateway

The gateway is the most technically involved part of the system. Every order has its own lifecycle, tracked by a eventSessionOrderId that threads through each step of a multi-page checkout flow: amount selection, address collection, seat or section selection, payment method choice, and final payment processing.

Two seating models are supported. General admission assigns buyers to a section rather than a specific seat. The section cards show real-time availability, and a get-seat / drop-seat API pair handles atomic seat claiming with concurrent buyer safety. Reserved seating lets buyers select individual seats from a visual layout. Each seat has stored position data — positionX, positionY, rotation, shape, sizeX, sizeY — allowing the venue's physical layout to be represented accurately in the browser.

Orders carry an expireIfNotCompletedAt timestamp. The gateway surfaces a countdown timer that shows buyers how long their held seats remain reserved. When the timer expires, the seats are released back to the pool without buyer action required.

Payment is handled through Stripe and PayPal, with distinct payment intent flows per provider. Both flows converge on the same order status model — PENDING, PAID, CANCELLED, REFUNDED — and both trigger the same downstream actions: order confirmation email, invoice generation, and seat status update.

Venue and Section Modeling

Venues are modeled with sections, and sections contain seats. Each section carries 2D spatial metadata — position, rotation, shape, and dimensions — that allows an accurate visual representation of the venue floor plan. Sections can be designated as standing (general admission) or seated (reserved). Seat availability within a section changes in real time as buyers move through the checkout flow.

The section model supports individual seat disabling, section-level pricing (startingPrice), and per-session price overrides stored as a JSON map (sectionPrices) on the event session. This allows the same venue layout to carry different pricing configurations for different events.

QR Ticket Validation

Both the artist panel and the venue panel include a ticket validator — a QR scanner interface that reads the order's PNR number from the attendee's ticket and validates it against the order database in real time. Validation is scoped: venue staff can only validate tickets for sessions at their venue; artist staff can only validate for sessions featuring their artist. The /api/public/validate endpoint handles validation logic and returns the order status.

Role-Based Access Architecture

The platform distinguishes between platform-level access (admin) and entity-level access (venue operators, artist managers). VenuePerson and ArtistPerson models link users to specific entities with a role field (OWNER, MANAGER). Middleware enforces that venue panel users can only access data for venues they are associated with, and artist panel users can only access data for artists they manage.

Notifications and Invoices

EJS email templates cover the full order lifecycle: order placed, order cancelled, order refunded, welcome, OTP, password reset, new login alert. Each template receives structured order data and renders a consistent branded email. Invoice generation produces both HTML and PDF formats, served as downloadable files from the attendee's account area.

SSO supports eight providers: Google, Facebook, Apple, GitHub, LinkedIn, Microsoft, TikTok, and Twitter. SMS notifications are handled via Twilio.