A community-theater ticketing service survived on-sale days after bot protection and caching landed

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Tickets for a few dozen community theaters across the region are sold through this platform; each theater manages its own events, pricing, and seating charts through a self-serve dashboard. Most shows sell at a gentle pace, but a popular production opens with an on-sale day that compresses weeks of demand into minutes. The company behind it is small — a founder, a support lead, and a contract developer. Patrons are ordinary ticket buyers — families, retirees, school groups — often purchasing from work or library networks, on phones, in a hurry before a show sells out.

What it was costing

Popular on-sale days brought scalper bots that bought out front rows within seconds, real patrons got error pages, and theaters blamed the platform; one musical's opening had to be re-seated by hand.

What they could see

• On one musical's opening on-sale, bots bought out the front rows within seconds of tickets going live.
• Real patrons hit error pages during the same minutes and called the theaters instead, blaming the platform.
• One production's seating had to be re-assigned by hand after the buyout, costing staff a full day.
• Theaters began asking whether on-sale day would work before they would list a popular show.
• Support learned about failures from angry patrons' calls, not from any alert or log.

The constraints we worked inside

• The ticketing app is a modest monolith that cannot be re-architected this year; protection must live in front of it.
• Bot defense must not block shared networks — patrons buy from schools, offices, and libraries behind shared egress.
• Theaters configure their own events; the protection rules must work without per-event tuning by the platform team.

What had been tried before

The contract developer added IP throttling to the checkout route for the last big on-sale.

Schools and offices share egress addresses, so real patrons tripped the throttle while the bots rotated through fresh IPs — it punished the buyers theaters wanted.

A CAPTCHA challenge was placed on the checkout form for one full season of on-sales.

Completion dropped as older patrons and phone users abandoned the puzzle wall, and the bots were solving it anyway within weeks — cost without effect.

Staff watched on-sale dashboards live and voided suspicious orders by hand afterward.

Vigilance scales to one theater, not a dozen simultaneous on-sales; the hand re-seating of one musical's front rows was the cost of that approach.

What we proposed

We proposed protecting the existing monolith from the edge: Cloudflare in front of the whole platform, Turnstile gating the checkout path — invisible for humans, expensive for bots — with seating charts, event pages, and images cached per event so on-sale crowds hit the edge rather than the origin. Managed WAF rules run by default with a logged challenge-passthrough path for support, because theaters configure their own events and nobody will tune rules per show. No re-architecture: the app keeps its shape, and the win comes from the layer the platform controls.

Just as important is what we ruled out, and why:

• A waiting room in front of every on-sale — Most shows sell at a gentle pace; forcing ordinary purchases through a queue to solve flagship spikes would depress sales and confuse patrons who expect instant checkout.
• Rebuilding checkout as an API-first service — The monolith can't be re-architected this year and the on-sale calendar wouldn't wait; protection had to arrive in weeks, at a layer the platform already controls.
• Per-theater custom rate rules — Theaters configure their own events; a dozen bespoke rule sets nobody maintains is how a mid-sale block becomes a support ticket with no one on call.

How the work ran

Delivered by the systems pod — engineer over 5 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Cloudflare

Protection must live in front of a monolith that won't be re-architected this year; the edge is the only layer the platform actually controls.

Turnstile

Invisible for humans and expensive for bots — no puzzle wall, which matters because patrons buy from phones and shared networks in a hurry.

Edge caching

Per-event cache keys absorb on-sale crowds at the edge for seating charts and event pages, leaving the origin to serve the checkout path alone.

WAF managed rules

Default-on protection works without per-event tuning, which no platform team can staff across dozens of self-serve theaters configuring their own shows.

Origin health monitoring

It separates protection working from origin struggling, so support escalates on evidence instead of guesses in the middle of a sale.

What went wrong

How we worked together

Cadence

A 25-minute call every Wednesday with the founder and support lead, an on-call window during the pilot theater's on-sale, and a written run-down after every protected on-sale.

Client side

The support lead joined every on-sale as the human escalation path; the contract developer reviewed the checkout integration changes before each release.

Decisions

Protection defaults were decided by the platform and documented; exceptions a theater requested were answered from passthrough-log evidence, not opinion.

They provided

Staging access to the monolith and its checkout flow, anonymized logs from the last three on-sales, and one friendly theater for the pilot.

What changed

The headline: subsequent on-sale days completed with bots challenged at the edge and origin load flat — Bot buyouts → protected on-sales, read from On-sale day logs. A second check: hand re-seatings required since protection went live at 0.

On-sale days became unremarkable, which is the point. The support lead opens the dashboard to watch ordinary traffic instead of bracing for the phone, and theaters stopped pre-apologizing to patrons in their own newsletters. The founder no longer talks a popular show out of listing on the platform, and the contract developer's week no longer contains a re-seating disaster to atone for. Patrons just buy tickets, and nobody congratulates them for managing it.

The result was read from On-sale day logs against the pre-engagement baseline over the stated window, with a guardrail check on hand re-seatings required since protection went live. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The managed-rules configuration with the challenge-passthrough path documented for support.
• An on-sale day checklist: dashboards to open, thresholds to watch, when to escalate.
• Turnstile and cache-key documentation per event type, written for the support lead.
• The pilot theater's evidence file — logs and outcomes — for reassuring nervous theaters.