Friday 9:00 a.m.: registration opens for an 800-seat conference. By 9:03, the site returns 503. By 9:15, screenshots are already circulating on social media. Comms panics, ops restarts Apache "to see," and nobody load-tested the payment page under real traffic.
An event website is not a blog that grows gradually. It is a compressed traffic window — sometimes just minutes — that you cannot replay. The right question is not "which host is best?" but which page must stay up, at what time, with what visible plan B?
Map launch day before choosing hosting
Start by separating flows:
| Flow | Typical load | Failure tolerance |
|---|---|---|
| Info pages (schedule, speakers) | High, mostly reads | Medium — a static fallback page works |
| Registration / ticketing | Extreme spike, DB writes | None — this is core business |
| Attendee area (badge, PDF) | Moderate, post-purchase | Low |
| Partner API / entry scanning | Variable | Low on event day |
Then quantify the credible worst case: how many concurrent requests at open? How many DB writes per second? A ticketing flow with a virtual queue is not the same as an embedded Google Form.
Useful sizing starts from the first click that scares you, not monthly Analytics averages.
Architecture: separate what must hold from what can wait
Three patterns that work in production:
1. Aggressively cached vitrine + isolated back office. Schedule, FAQ, venue map: static or CDN with long TTL. Ticketing runs on a subdomain or dedicated service with connection pooling and Redis sessions.
2. An explicit queue. Better to show "you are #847" on a stable site than an infinite spinner followed by 503. Static pages plus JWT tokens or a dedicated queue service avoid exploding PHP-FPM at once.
3. Temporary scale-out. On cloud (OVH Public Cloud, Scaleway, Hetzner Cloud), prepare an image or snapshot, a scale-out script, and especially automated scale-down — otherwise you pay for three servers until December for a June event.
Hosting: shared, VPS, or elastic cloud?
| Event profile | Sensible product | Why |
|---|---|---|
| Conference < 500 seats, simple form | Modest VPS + CDN | Control cron, PHP, Redis |
| Festival, third-party ticketing (Eventbrite, etc.) | Shared or static | Critical load is outsourced |
| In-house ticketing, spike > 1000 req/s | Cloud + load balancer | Elasticity and DB isolation |
| Integrated live streaming | Video CDN + separate origin | Video must not share PHP-FPM |
Shared hosting most often fails on three limits: concurrent MySQL connections, PHP-FPM workers, and no fast scale-out. That is not bad faith from the provider — it is a model built for smoothed traffic.
Observability and runbook: launch day is not improvised
Two weeks before, define:
- Who watches what: CPU, TTFB latency, 5xx errors, MySQL queue depth, Redis connections.
- Alert thresholds with mobile numbers, not email only.
- Written runbook: "if 503 > 2 min → enable static page / disable search / raise workers."
- Code freeze: no deploy the night before except a validated hotfix.
Test database restore — not "we do backups," but "here is how long to bring ticketing back at 8:55 a.m."
The peak: the spike is predictable; failure should not be
"Unlimited hosting" does not replace load testing, queuing, or a fallback page. Datacenter prestige matters less than mapping the first fifteen minutes.
Decide and move forward without blind spots
- Identify the one page that must not fail (usually payment or registration confirmation).
- Cache or static-serve everything else at least 72 hours before open.
- Load-test that page with a realistic scenario (not an A/B test on the home page).
- Document plan B: static page, comms message, extended sales window.
- Plan the descent: scale-down, billing, log archival.
Compare elastic offers in our directory and compare tool. For caching, see Dynamic page cache: decide what can really be cached.
Frequently asked questions
Should you oversize the server all year for one day?
No. Use cache, CDN, temporary scale-out, or elastic architecture for the spike, then return to normal cost.
Is shared hosting enough for an event site?
Rarely for ticketing or concentrated registration opens. A VPS, elastic cloud, or static pages plus a separate API is more realistic.
When should you enable a CDN for an event?
As soon as info pages are stable — weeks before. On the day, you monitor; you do not configure.
What should you test before sales open?
Load test on the critical page, database failure simulation, documented fallback to a static page.
An event gives you one shot. Size for that quarter-hour — and sleep the night before because the runbook is written, not because the server is oversized all year.