A ticketing and event-operations platform for an Egyptian concert/event promoter — an empty NestJS skeleton became a near-complete backend platform in about three weeks.
We are recording a voice-over walk-through of Spotlight Egypt's primary features, dashboard modules, and server operations. In the meantime, explore the complete system architecture details below!
13 domain modules — Auth, Users, Artists, Venues, Events, Tickets, Orders, Payments, Refunds, Coupons, Access Codes, Notifications, Analytics, Checkins — designed and built end to end by one engineer, deployed on Render.
Google/Facebook OAuth and email OTP (Brevo) for customers; email + password + TOTP MFA for Admin and Organizer accounts; scoped Gate Staff logins. Redis-backed sessions and server-side RBAC enforce not just roles but per-event resource ownership.
Capacity-tier inventory (VIP/Regular/...) is protected with a Redis atomic counter; seat-map inventory (individually numbered seats) uses a Redis distributed lock per seat — two different concurrency mechanisms chosen deliberately per allocation type, not one stretched to fit both.
Paymob's Intention API and Unified Checkout handle payment collection; every processed webhook event ID is stored before an order is marked paid, so retried or duplicate callbacks can't double-fulfill an order. A narrower, checkout-scoped admission-token queue protects the payment step itself under load — deliberately not a site-wide waiting room.
Refunds process at the individual ticket, so partial refunds within a multi-ticket order work. Requests outside the event's normal policy, or above a value threshold, route to Admin for approval before they ever reach Paymob.
Order-paid and refund-succeeded events stream straight to an Admin/Organizer dashboard in real time — tickets sold, revenue, refund rate, and check-in progress — Organizer scoped to their own events, Admin seeing everything.
Order, refund, and event-lifecycle emails (via Brevo) run as background jobs on a Redis/BullMQ queue, so sending a confirmation email never competes with the latency-sensitive checkout request itself.
Hover or click on the system modules to inspect their dynamic interactions and roles within the product stack:
App Router, TypeScript, Tailwind v4, next-intl for EN/AR routing. Marketing site live in production; storefront (browse/hold/checkout) is being wired up to the now-complete backend.
Architecture mapping diagram is currently loaded in the interactive matrix viewer on the left.
Considered a site-wide virtual waiting room with queue positions and admission tokens, then explicitly rejected it after discovery — ticket holds plus atomic inventory operations were confirmed as sufficient protection, keeping checkout honest: a buyer either gets the ticket or sees it's gone, no fake waiting state. A much narrower, checkout-scoped admission queue was later adopted specifically to protect the payment step — a distinct decision, not a reversal.
Resolved with two different concurrency mechanisms instead of forcing one to fit both: a Redis atomic counter safely decrements capacity-tier inventory under concurrent holds, while seat maps use a Redis distributed lock scoped to the individual seat.
Every processed gateway event ID is stored before an order is marked paid or a ticket is issued, so a retried or duplicated webhook can't double-fulfill an order or generate duplicate tickets.
Ran a follow-up discovery session that corrected course: Spotlight Egypt runs its own events only, so the data model dropped tenant scoping entirely — the roles settled as Admin (platform-wide) and Organizer (scoped to their own events) instead of a speculative tenant hierarchy that didn't reflect the real business.
Scaffolded the Turborepo monorepo, shipped the bilingual (EN/AR, RTL-aware) marketing site, stood up a NestJS backend skeleton, and ran four rounds of business/product/architecture discovery — resolving the single-organization model, Paymob as payment gateway, and concrete status-enum-driven domain design before writing domain code.
Shipped Google/Facebook OAuth, email OTP (Brevo), Admin/Organizer password + TOTP MFA, Gate Staff accounts, Redis sessions, and server-side RBAC — plus the matching sign-in and account UI — verified end to end against real dev infrastructure.
Built the full catalog domain — Artists/Venues, Event lifecycle and reschedule, and Tickets with both allocation strategies — resolving and implementing both overselling-prevention mechanisms (Redis counter for tiers, Redis lock for seats).
Built Orders and checkout, the Paymob adapter and idempotent webhook fulfillment, the checkout queue, ticket-level refunds with approval routing, coupons, and presale access codes — while migrating backend hosting from DigitalOcean to a Dockerized Render deployment.
Wired the BullMQ/Brevo notification pipeline, a WebSocket-powered live Admin/Organizer analytics dashboard, and QR-based Gate Staff check-in scanning.
With the backend essentially feature-complete, current work is connecting the customer-facing browse/hold/checkout experience to it, ahead of an offline-capable PWA check-in flow and platform-resilience hardening.
Interested in discussing similar system integrations?