Festaff FestaffCapacity & launch-day design
When applications open for a festival like Glastonbury, thousands of would-be crew try to sign up in the same few minutes. This is how Festaff is built to take that moment — and what we turn the wait into instead of a blank loading screen.
The real bottleneck
Most of what a launch-day crowd does is look — which festival's open, what the role involves, the FAQs. That scales almost for free. The actual risk is 12,000 people submitting an application in the same ten seconds — that's a database write storm, and it's where a naive setup falls over.
Festival listings, role details, FAQs are built once and served from cache (ISR on Next.js/Fargate, behind the same load balancer already running Artisan and Doctor Grow). Tens of thousands can browse at once without touching the database.
Every submitted application is a write. Instead of letting all 12,000 hit the database in the same instant, writes are shaped through a queue with a sane pace — the ALB and Fargate fleet still autoscale on demand, but the database only ever sees what it can actually commit safely.
What people actually see
Instead of a spinner or an error page, anyone caught in the launch-day rush lands in the Green Room — a proper backstage-style waiting space themed like the rest of Festaff, not a bare "you are number 4,812 in the queue" page.
Live mock-up
A real queue position, an honest wait estimate, and something worth sticking around for — festival photos, crew stories, and a host to talk to. Nobody stares at a blank screen.
Who's hosting the wait
While people wait, they can talk to the Green Room host — a chat concierge who covers the lineup, what the crew role actually involves, and general questions, instead of everyone just staring at a progress bar.
Talks lineup, logistics, and "what does the job actually involve" while you wait — a concept for this page, not a live AI yet. Pick a question below.
Concept demo — scripted replies, not a live AI in this preview.
Not a hypothetical add-on: Eskdale Solutions, who build Festaff, already build and support AI receptionists, phone systems and office automation for clients as a live service line — a real Ren would be built on that same capability, not a one-off for this pitch.
Launch-day measures
Browsing pages are pre-built and served from cache, not rendered fresh per visitor — the biggest share of launch-day traffic costs almost nothing.
The same load balancer and container fleet already running Artisan and Doctor Grow scale horizontally on demand — the app layer isn't the bottleneck.
Applications are queued and committed at a rate the database can sustain, so 12,000 simultaneous submits don't turn into 12,000 simultaneous failures.
Honest caveat: these are the right building blocks, proven on the same platform running two live sites already — but the actual numbers (queue depth, real wait times) only get sharp once we're tuning against real launch-day traffic, not estimates. That's the plan, not a guarantee.