A sports federation's registration day went from crash to queue — and thousands more kids got registered

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

Youth leagues across a region — soccer, baseball, basketball — are organized by this federation, with each club run by parent volunteers and every registration flowing through one annual opening. The technical infrastructure is a PHP application on a single server, maintained for years by one retired volunteer. The board sets policy, the treasurer guards a community budget, and fairness — every family gets an equal shot at a roster spot regardless of connection or zip code — is written into the league's charter, not just its marketing.

What it was costing

Registration opens once a year at a announced time; last year the volunteer-run infrastructure died in eleven minutes, parents refreshed error pages for hours, and the federation's inbox became a complaint desk for a week.

What they could see

• Last year's registration opening survived eleven minutes before the server died, with hundreds of families still in line.
• Parents refreshed error pages for hours, and the federation's inbox became a complaint desk for a week.
• Volunteers answering phones had nothing to tell families — no queue, no status, no estimate of when it would work.
• The crash favored whoever persisted longest, not a fair order — exactly what the charter says it won't tolerate.
• The volunteer who maintains the system took the failure personally and talked about stepping back entirely.

The constraints we worked inside

• The registration app is a volunteer-maintained PHP relic; it will not be rewritten before this season — protection must be external.
• The spike is a known date and time; the architecture can prepare, but the budget is a community organization's.
• Equity matters: protection must not favor fast connections or tech-savvy parents over others.

What had been tried before

The opening time was moved earlier in the morning on the theory that fewer parents would be awake.

The crowd moved with it — the spike arrived intact at the new time, and families who missed the announcement found a site already down.

The registration form was rebuilt on a hosted form service and embedded into the old site one year.

The embed died under the same spike as the page around it, and the service's free tier throttled submissions exactly when it mattered most.

A paper-first week was offered, with online registration opening a week later.

Paper forms were keyed in by the same volunteers who maintain the site, working parents lost their fair shot, and online demand when it opened was undiminished.

What we proposed

We proposed an external layer for a relic that wouldn't be rewritten: a Cloudflare waiting room admitting registrations in order with a randomized first shuffle — the fastest connection stops winning, which was the fairness requirement stated in the league's charter. Everything that isn't the registration form — schedules, program pages, documents — caches at the edge, leaving the origin one job: take registrations. A status page and queue-position messaging would set expectations in plain language, converting the complaint desk into a posted wait time that families can plan around.

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

• Rewriting the registration application this season — It's a volunteer-maintained PHP relic and the date is fixed; a rewrite is a next-year conversation, and this year's families needed this opening to work.
• A paid registration service with slot booking — Per-family fees across thousands of registrations, plus a new flow families would learn on the most important morning of the league year — fairness shouldn't favor the adaptable.
• A simple first-come queue without a shuffle — First-come rewards the fastest connection and the tech-savvy household, which is precisely the outcome the charter's fairness rule exists to prevent.

How the work ran

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

The stack, and the reasoning

Cloudflare

An external layer was the only option for a PHP relic that won't be rewritten before season; the edge absorbs the spike before it reaches the volunteers' server.

Waiting room

Admitting in order with a randomized first shuffle makes the fastest connection irrelevant — the equity constraint shaped the mechanism itself, not just its documentation.

Edge caching

Schedules, program pages, and documents leave the origin with one job — take registrations — which is the difference between an hour of capacity and a full day.

Status page

A posted wait time converts the complaint inbox into an expectation; families will wait when they can see the line and trust the order.

Origin health alerts

Volunteer admins see strain before families do, with a one-line escalation path to us throughout the registration window itself.

What went wrong

How we worked together

Cadence

Weekly evening calls around the volunteers' day jobs, a rehearsal with parent volunteers two weeks out, and a chat channel staffed continuously through registration day.

Client side

The retired volunteer owned the PHP app and stayed on for the season; a board member owned family communications and the status page wording.

Decisions

The board ratified the fairness rules once; everything else was decided in the calls, and on registration day the channel made calls in minutes.

They provided

Server access alongside the volunteer, last year's registration logs for capacity math, and a dozen parent volunteers for the rehearsal.

What changed

The headline: registration stayed open and orderly for the entire day, processing every queued family — 11-minute crash → full-day queued capacity, read from Registration completion log. A second check: registrations completed vs the prior year at +4,000.

Registration evening felt boring, which the board named as the goal. Families queued, watched a number move, and registered; the complaint inbox stayed quiet enough that volunteers answered real questions instead. The retired volunteer stopped describing the system as held together with tape. The board now plans seasons around capacity it can see, and fairness stopped being an aspiration that collapsed at seven o'clock once a year.

The result was read from Registration completion log against the pre-engagement baseline over the stated window, with a guardrail check on registrations completed vs the prior year. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The queue configuration with fairness rules documented for future boards to read.
• A plain-language registration-day script for the status page and parent messaging.
• Rehearsal findings from parent volunteers, including the questions that reshaped the copy.
• Origin health alerts configured with the volunteer's escalation path for the season.