Rebuilt international music festival’s site for peak traffic

An international music festival came to us in the lead-up to their next event. Their website had two compounding problems. First, the site couldn’t reliably handle the traffic spike during the week-long festival, when tens of thousands of attendees, performers, sponsors, and press were hitting the site simultaneously for schedules, venue maps, artist profiles, and ticketing. Performance degraded; occasionally the site went down entirely.

Second, their previous hosting situation had a backup compromise: the only backup source they had access to had been damaged, and they’d lost production data leading to tremendous amounts of lost time and irrecoverable historical data. The institutional memory of that loss colored every operational decision they made. The team had developed informal habits around protecting against the loss (keeping local copies of edited content, hesitating to make changes when a backup hadn’t been verified) that ate into their operational efficiency well outside the actual incidents.

They needed a rebuild for the traffic problem and a completely different backup posture so the data-loss situation couldn’t repeat. The festival’s calendar gave a hard deadline: the new site had to be live and proven through pre-festival traffic before the next event hit.

The traffic-spike challenge.

A festival site’s traffic profile is fundamentally different from a typical content site’s. Most of the year, traffic is modest: people researching the upcoming event, ticket buyers in scattered waves, performers and sponsors checking schedules and information. Then for one week of the year, traffic spikes by orders of magnitude as the actual festival happens. Attendees pull up the schedule on their phones throughout the day. Out-of-town family check in for updates. Press refresh artist profiles. Sponsors monitor mentions. The site has to handle peak loads that would crush most websites entirely while staying responsive enough that an attendee in a noisy festival environment can pull up the next set time in seconds.

The architectural answer to this kind of load profile isn’t “buy more server,” because that approach pays for capacity year-round that’s only needed one week per year. The answer is infrastructure that scales elastically: handles modest loads cheaply during normal months, scales up automatically during peak, and never requires manual capacity planning.

What we built.

We started with the platform itself: a custom WordPress build designed for the festival’s actual usage patterns. The schedule, artist profiles, venues, and sponsor information all became content types editors could manage cleanly in the admin. The data model reflected how festival programming actually works: performers booked into time slots at venues, with relationships between artists and venues and sponsors that let the editorial team update one and have all the connected information stay accurate.

Performance optimization was structural, not a plugin: efficient queries, edge caching, image optimization, lazy loading where appropriate. Every page was profiled and tuned so the typical request completes quickly enough that the system can serve many concurrent visitors per server before scaling becomes necessary. WCAG-AA accessibility was built in from the start, not retrofitted, which matters for an event with international audiences.

For the hosting layer, we moved them onto our managed hosting with the architecture designed for traffic spikes: auto-scaling worker pools that add capacity automatically as load increases, edge caching that absorbs most traffic at the CDN before it reaches the origin server, and a CDN serving static assets globally close to wherever attendees and viewers were located. The combination means that during the festival, the vast majority of page requests are served from edge caches without ever touching the origin WordPress install. Only authenticated editor sessions and dynamic personalized content actually hit the origin, which keeps the origin’s load profile reasonable even during peak traffic.

The backup architecture.

The backup architecture was critical. Real-time backups of the database (every change captured as it happens) plus daily file backups, all retained for 30 days, stored in two completely separate secure locations. A compromise of one storage destination still leaves a clean copy in the other. The team can request restorations at any point in the retention window.

The design intent: even if the worst-case scenario happens again (one backup destination compromised, lost, or otherwise unavailable), the second destination is independent enough that production data remains recoverable. The “we lost our backups too” failure mode is engineered out of the system by making the two backup destinations operationally and physically independent, not just nominally separate.

Real-time database backup also addresses a subtler failure mode: data loss between the last daily snapshot and the moment of compromise. With daily-only backups, a compromise discovered at 4pm means losing whatever was edited or published since the previous night’s snapshot. With real-time database backup, recovery can target a specific point in time within the retention window, which means an editor’s three hours of work that happened between snapshots isn’t lost just because something happened later in the day.

Editorial confidence and the operational shift.

The combined effect of the new platform and the resilient backup architecture wasn’t just technical, it reshaped how the editorial team operated during the festival. Updates that had previously required engineering escalation (because they touched parts of the site nobody trusted to edit safely) became routine self-service. The schedule could be updated in real time as set times shifted. Sponsor acknowledgments could be added the moment they were confirmed. Performer bios could be edited live without the team worrying that the change would propagate to a destabilized site.

That shift in operational confidence is the part most prospective clients underestimate going in. A site that the team trusts to handle whatever they do to it during the highest-stakes week of the year becomes a different kind of tool than a site they’re trying not to touch in case it breaks. The festival’s editorial output during the event became more responsive, more thorough, and more accurate because the underlying platform was no longer a brittle constraint.

What this case study illustrates.

Sites that handle dramatic traffic variability (events, launches, viral moments) require platform-level architecture and hosting-level scaling. Sites that have been burned by lost backups require not just better backup tooling but a fundamentally different backup architecture. Both problems are solvable, but they need to be addressed at the infrastructure level, not patched at the application layer.

The festival case is unusual mainly in its extremes. The traffic peaks are larger and the backup loss had been more painful than most engagements. The architectural answers, though, generalize well: any site that has periods of high load benefits from edge caching and auto-scaling, and any site holding data the team can’t afford to lose benefits from real-time backup to two physically separate destinations. The principles are the same; the festival just makes the case for them especially clearly.