UNI_TICKET

• 

  UNI_TICKET is a unified API for seamless ticket discovery, booking, and purchase across events, travel, and cinemas.

Inspiration UNI_TICKET was inspired by the fragmented, fragile ticketing systems used for events, travel and cinema — each with different APIs and auth flows. The goal was a unified, developer-friendly microservices SDK and demo platform that makes booking, inventory and payment integration consistent and easy to extend.

What it does UNI_TICKET provides a small microservices ecosystem that demonstrates:

Centralized API Gateway routing and JWT-based identity propagation. Auth service for user management and email/OTP flows. Booking service that coordinates platform-specific bookings (movies, flights, rail, events). Venue service for venues, halls and seat inventory. Payment service with webhook handling (stubbed provider). Dockerized services and an end-to-end test to validate routing and health checks. Designed as a reusable SDK and reference architecture for building ticketing systems. How we built it Language / stack: Go for all services (net/http, gorilla/mux), MongoDB for persistence, Redis for optional caching/locks. Architecture: small independent services (Auth, Booking, Payment, Venue) behind a ReverseProxy API Gateway. Services communicate over HTTP; gateway injects X-User-ID from JWT. Dev tooling: Dockerfiles per service, docker-compose for local integration, .env templates, and a test folder with an e2e Go test that verifies gateway → venue routing. Repo follows layered structure: handler → service → repository, with shared utilities factored for DRY. Challenges we ran into Time constraints: implementing end-to-end interactions and tests under a tight hackathon deadline required prioritizing core flows (health, routing, booking/seat basics) over full feature parity. Consistency across services: avoiding duplicated utilities and ensuring module paths/imports were consistent across many small Go modules. Testing infrastructure locally: coordinating Mongo/Redis containers and service ports so the gateway routing and e2e tests run reliably. Accomplishments that we're proud of Completed a multi-service demo with a functioning API Gateway that routes and injects identity headers. Implemented venue/seat models, repository patterns, and booking flow scaffolding suitable for extension. Dockerized each service and provided a docker-compose-ready setup for quick local runs. Added an automated e2e test to validate gateway-to-service routing quickly during the demo. What we learned How to design and implement a small but realistic microservices topology with a lightweight API gateway. Practical trade-offs for local development: using docker-compose service names for networking, and local JWT parsing vs. token introspection. The importance of shared utility packages to avoid drift across services in a monorepo. What's next for UNI_TICKET

Planned improvements and next steps:

Add inventory locking (Redis-based) and seat reservation atomicity integrated with Booking-service. Implement payment provider integrations and idempotent webhook handling. Move token validation to introspection endpoint in Auth-Service (centralized auth). Add more e2e scenarios, CI workflow, and example client SDK (JS/Python) to consume the gateway.

Built With

• ci/cd
• fiber
• golang
• jwt
• mongodb
• razorpay
• redis