Ticket Booking Platform

The Challenge

A multi-role ticket marketplace must keep authentication, seller onboarding, event approval, ticket availability, bookings, sales, payments, and money movement consistent across several user journeys. The platform also needed secure password recovery, time-limited verification tokens, reliable email delivery, cache-aware lookups, and protected admin access without exposing sensitive account information.

The Impact

The architecture establishes a scalable event commerce foundation with controlled seller access, structured booking and payment states, traceable transactions, Redis-backed security workflows, and responsive user experiences for marketplace discovery and administration.

Ticket Platform Home

Operations Dashboard

Sign In

Seller Onboarding & Approval

• Seller registration collects name, contact, identity, company, and address information.
• Zod validates submitted fields before user creation.
• bcrypt hashes seller passwords before MongoDB persistence.
• New seller accounts begin unverified with a pending administrative approval status.
• Email verification uses a token and email pair, hashed token storage, a 24-hour expiry, and one-time invalidation.
• Verification status checks query Redis first and fall back to MongoDB when the cache is unavailable.
• Resending a verification email invalidates the previous token before creating a replacement.

Events & Ticket Inventory

• Sellers create events with title, description, date, time, location, collection, subcollection, and banner image data.
• Events move through draft, pending, approved, or rejected states before publication.
• Admin approval records the approving user and approval timestamp.
• Each event supports multiple ticket types with price, total quantity, remaining inventory, and availability state.
• Event collections support structured marketplace browsing and categorization.

Booking, Sales & Payments

• Buyers create bookings against an event with ticket type, quantity, total amount, booking state, and payment state.
• Booking states distinguish pending, confirmed, cancelled, and failed workflows.
• A completed booking can connect to one sale containing ticket quantity, total price, and sale status.
• Buyer information is stored against a sale for fulfillment and contact workflows.
• Payment records support card and PayPal methods with pending, completed, or failed statuses.
• Payment references and timestamps support traceability across completed purchases.

Authentication & Session Management

• NextAuth exposes sign-in and session endpoints through the application API.
• Credential authentication validates email and password before comparing bcrypt hashes.
• JWT-backed sessions carry user identity and role information across protected workflows.
• Redis caches frequently accessed user data to reduce repeated database reads.
• Authentication logic checks account verification status and returns controlled custom errors when access requirements are not met.

Password Recovery Security

• Forgot-password requests are validated through Zod before processing.
• The endpoint always returns a generic response, preventing attackers from discovering registered email addresses.
• Cryptographically secure reset tokens are hashed and stored in Redis with a one-hour expiry.
• Reset requests verify both the token and associated email before changing credentials.
• New passwords must satisfy validation rules and are persisted only after bcrypt hashing.
• Successful resets invalidate tokens immediately, making each reset link single-use.

Financial Transaction Model

• Transactions connect each sale to sender, recipient, and processing administrator records.
• Transaction types distinguish buyer payments, administrative payments, and seller payments.
• Direction fields record incoming and outgoing money movement.
• Amount, currency, status, reference, processing user, and timestamps provide an auditable financial trail.
• Pending, completed, and failed states support controlled settlement workflows.

Data Architecture

• The Prisma schema models users, events, tickets, bookings, sales, buyer information, payments, transactions, settings, and event collections.
• MongoDB ObjectIds connect relational-style Prisma associations across marketplace records.
• Unique email, user ID, sale, payment, booking, and settings constraints protect important one-to-one or identity relationships.
• Created and updated timestamps provide lifecycle visibility across accounts, events, bookings, and platform settings.
• Enumerated roles and workflow statuses keep approval, booking, payment, and transaction state transitions explicit.

Email & Token Services

• Nodemailer sends seller verification, password recovery, and account approval or rejection emails.
• HTML templates inject user-specific links and status information into each message.
• Token utilities handle cryptographic generation, hashing, expiration, storage, retrieval, and invalidation.
• Separate Redis mappings connect tokens and emails while avoiding raw token persistence.
• Retry-aware error handling supports more dependable email workflows.

Frontend & Engineering Tooling

• Redux Toolkit and React Redux provide shared client state while SessionProvider exposes authentication state.
• Framer Motion, Swiper, and Embla Carousel support animated and media-rich user experiences.
• Next Image is configured for GitHub avatars, TMDB artwork, media sources, and Unsplash content.
• Biome, ESLint, TypeScript, and Husky support formatting, validation, and commit-time development quality.
• Prisma generation and deployment scripts prepare the data client and synchronize schema changes.

Contribution Note

• The supplied schema and API documentation verify the platform architecture and implemented modules.
• They do not identify which teammate authored each feature.
• The personal-contribution section should be finalized using Git commits, pull requests, or a written list of the modules completed by Methum.