What Is EventHub?
EventHub is a production-grade event ticketing platform that handles the full lifecycle of an event — from creation and ticket sales to QR code validation and post-event analytics. It's built for three distinct user types: event organizers, customers, and administrators — each with their own portal and permission set.
The project runs on .NET 9 for the API and React with TypeScript for the frontend, with 24 comprehensive tests covering authentication, event management, ticket processing, and analytics.
Tech Stack
- Backend: ASP.NET Core Web API (.NET 9), Entity Framework Core, JWT authentication, Swagger/OpenAPI
- Frontend: Next.js, React, TypeScript, responsive mobile-first design
- Database: SQL Server with indexed queries and connection pooling
- Testing: xUnit with FluentAssertions — 24/24 tests passing
- DevOps: GitHub Actions CI/CD, Docker-ready, Azure/AWS deployment-ready
Architecture: Three User Portals
The platform is structured around three distinct roles with strictly enforced permissions at the API layer — not just hidden in the UI.
Event Organizers can create events with multiple ticket tiers, set capacity limits per tier, configure promotional codes, and view real-time analytics on revenue, demographics, and remaining capacity. Creating a tiered event looks like this:
const event = await api.events.create({
name: "Tech Conference 2025",
capacity: 500,
ticketTypes: [
{ name: "Early Bird", price: 299, limit: 100 },
{ name: "Regular", price: 399, limit: 300 },
{ name: "VIP", price: 599, limit: 50 }
],
promotions: ["EARLY25", "GROUP10"]
});Customers get a seamless booking experience — browse events, select ticket types, apply promo codes, pay via Stripe, and receive QR-coded tickets. They can track order history and manage bookings from their portal.
Administrators have full system oversight: all events, all transactions, user management, and business analytics.
Real-Time Capacity Management
Overbooking is one of the hardest problems in ticketing systems. Two customers booking the last seat simultaneously is a classic race condition. I solved this using optimistic concurrency in Entity Framework Core — every capacity update includes a row version check, so if two requests try to claim the last ticket at the same time, one wins and one gets a clean conflict error with a prompt to retry.
The capacity state is surfaced to the frontend in real time, so customers see live availability without polling aggressively.
Security-First Design
Security was designed into the system from day one, not added afterwards:
- JWT with refresh token rotation — access tokens expire quickly; refresh tokens rotate on each use, making token theft ineffective
- Role-based authorization at the controller level — organizers cannot access admin endpoints even if they construct a valid request manually
- Input sanitization on all endpoints — preventing injection attacks at the API boundary
- Secure file upload with MIME type validation and size limits
- Audit logging — every sensitive action is logged with user ID and timestamp for compliance
Test-Driven Development: 24 Tests
The test suite covers every critical path in the system:
- Authentication and security — 6 tests covering JWT validation, password rules, and authorization boundaries
- Event management — 5 tests covering creation, updates, capacity validation, and deletion
- Ticket processing — 7 tests covering purchase flow, overbooking prevention, promo codes, and refunds
- Analytics and reporting — 4 tests covering revenue calculation and demographic aggregation
- Integration tests — 2 end-to-end workflow tests
Writing tests first forced me to design clean, testable business logic. The booking service has no dependencies on the HTTP layer, which means it can be tested in isolation with no database or web server running.
QR Code Ticket Validation
Each purchased ticket generates a unique QR code containing a signed token. At the venue, staff scan the QR code which hits POST /api/tickets/validate — the API verifies the signature, checks the ticket hasn't been used, and marks it as validated. The entire validation flow completes in under 200ms, which matters when there's a queue at the door.
Analytics Dashboard
The analytics endpoints expose revenue breakdowns, ticket type distribution, demographic data, and capacity utilisation — all queryable by event, date range, or organizer. The frontend renders these as interactive charts, giving organizers actionable insights into what's selling and who's buying.
CI/CD With GitHub Actions
Every pull request runs the full test suite automatically. The pipeline builds the .NET API, runs all 24 tests, and blocks merges if any test fails. This means the main branch is always in a deployable state — a requirement I set from the start of the project.
Performance
- API throughput: 1000+ requests per second under load testing
- Average database query time: under 50ms (achieved through proper indexing)
- Page load time: under 2 seconds for the React frontend
- Memory footprint: under 100MB under normal load
Key Lessons
- Optimistic concurrency in EF Core is the right tool for high-contention scenarios like ticket sales
- JWT refresh token rotation is worth the added complexity — it significantly limits the blast radius of token theft
- Writing tests first produces cleaner architecture — you can't write a unit test for code that has hidden dependencies
- CI/CD is not optional for production systems — automated testing on every PR catches regressions before they ship
- Swagger documentation is not just for external consumers — it's invaluable during development when the frontend and backend are built simultaneously
Get the Code
The full source is on GitHub. Clone it, run dotnet ef database update, start the API and the Next.js frontend, and you'll have a working ticketing platform in minutes.
If you need a ticketing system, booking platform, or similar event management solution built for your business, get in touch.