Collect everything, pay out later
Separate charges and transfers: the platform collects the full amount and transfers to each organiser in batches from the admin panel, so fees, refunds and disputes don't depend on each connected account.
03 / 04Event ticketing
QuickVoucher
Multi-tenant ticketing platform. Selling access to a 2,000-attendee event in November 2026.
- My role
- Design, code, scanner apps and deployment
- Year
- 2026
Stack
Next.jsStripe ConnectBullMQRedisCapacitorPWA
- commits
- 237
- attendees at one event
- 2.000
- data models
- 34
- apps: web, PWA, native
- 3
01The problem
Party and event organisers who sell their own tickets. Each one gets a store on their own subdomain, takes payments through Stripe and checks people in at the door with a phone. The platform collects the full amount and pays out later, so fees, refunds and disputes are handled in one place.
02What I built
- 01A store per organiser on their own subdomain, with an embeddable widget for their site
- 02Tickets, season passes and paid guest lists
- 03Stripe Connect with separate charges & transfers and batched payouts to each organiser
- 04A virtual waiting room for the highest-demand on-sale moments
- 05Background jobs with BullMQ and Redis
- 06PWA and native scanners that validate QR tickets at the door, even offline
03Decisions that matter
A queue that survives the spike
When tickets go on sale, a Lua script in Redis atomically decides who gets in: it clears expired sessions, counts free slots and lets the next batch through at once. Postgres never sees the spike.
Every operation exactly once
Sensitive operations carry an idempotency key with SET NX in Redis: a retry never does the work twice, and the database is spared the pressure.
Isolation per organiser
An organiser's queries go through a Prisma client scoped to their tenant, so a forgotten filter can't leak someone else's data.
04In motion
Acceso · Puerta A
1284 / 2.000
QuickVoucher
Festa Major 2026
14 NOV · 22:00 · General
QV-8F2K-91XA
Ruben L.
Ruben L.
VÁLIDA ✓