A sales day stress-tests every link in the chain.
Ralph Lauren’s national sales events behave less like a normal retail day and more like a ticket release. Customers wait for the reservation window to open, then thousands hit the form at the same minute. Off-the-shelf event tools rate-limit, time out, or charge per-ticket fees that don’t scale at this volume - none of them were built for a brand-led release that runs across multiple venues in parallel.
On the day itself the challenge inverts. Doors open. The queue builds. Every second a staff member spends on a paper list or a slow check-in screen becomes a real-world line. We needed door checks to be instant, parallel walk-up handling so the pre-booked line never stalls, and a single source of truth that HQ could watch in real time across every venue.
“Doors open. The queue moves.”
The brief we held ourselves to.
Design for the worst minute of the day. The other 23 hours come free.
We started from the load profile, not the feature list. Mapped the release-window arrival curve, modelled the door-throughput curve an hour later, then worked backwards into the architecture both surfaces needed.
- Separate reads from writes. Cached read paths absorb the “is the window open?” refresh storm; reservations queue into the write layer so the database is never the bottleneck.
- Three surfaces, one schema. Customer web, staff scan app, and venue kiosk all read and write the same reservation record. No reconciliation jobs, no end-of-day exports.
- QR over email, not over app. No customer-side install. Reservation confirmation email carries the QR. Works on every phone, every browser, every customer - including the ones who only check email at the venue.
- Kiosk as the relief valve. Walk-up customers and lost-email cases route to a tablet kiosk at the entrance. The main door stays scan-only. The pre-booked line never has to absorb a registration step.
Five components, one event-day system.
Each surface owns its job and stays out of the others’ way. The customer never sees the admin. The admin never needs to scan. The kiosk never blocks the scanner. Decoupled by design.
Mobile-first, sub-second response under spike load. Venue + time-slot picker, contact details, instant confirmation.
Generated server-side, embedded in the confirmation email, delivered within seconds. No app install. Works on any phone.
Open, scan, see valid / used in under a second. Offline-tolerant - re-syncs when the connection comes back.
Tablet at the entrance. Walk-up registers, generates ticket, scans through - handled in parallel to the main door queue.
Real-time reservations, check-ins, no-shows, kiosk walk-ups. Venue managers see their own venue; HQ sees the whole network.
In production across multiple national sales venues.
On event days the reservation window opens without throttling. Tickets arrive in inboxes within seconds. Staff move customers through the door at scan-speed. Walk-up customers flow through the kiosk in parallel. The pre-booked line never queues behind a registration step - which is the small operational detail that decides whether the room feels efficient or chaotic.
The same architecture pattern extends naturally to other retail releases, exhibitions, and high-volume in-store events. The components are independently reusable - a brand can adopt only the QR ticket flow, or only the staff scanner, or stand the whole stack up for a single event weekend.
- Backend
- PHP, MySQL, Redis cache, queued writes
- Customer web
- Responsive web - no app install required
- Staff app
- iOS (Swift), Android, offline-tolerant
- Kiosk
- Tablet-optimised web app for venue entrance
- Infrastructure
- CDN-fronted assets, queue-backed writes, spike-load tested
- Delivery
- Multilingual senior team · JTS-supported
Have a high-volume event coming up?
A 30-minute call covers fit, scope and what the architecture would look like for your venue count and traffic profile.
