Estimate how many families will register in the first ten minutes, test the registration system at that load on its own hosting, and move every step you can, such as accounts and details, ahead of opening time.

Nine o'clock on a Saturday

A swim club opens registration for the fall session at nine on a Saturday morning. Places in the popular classes are limited, and parents know it.

At nine they are all on the site at once, on laptops and phones, with cards ready. Within a few minutes pages load slowly, then not at all.

Some parents see error pages. Some are charged without a confirmation, and some press the button again and are charged twice. The office spends the next week sorting it out.

Why a busy form is harder than a busy page

A website can serve a popular page to many people cheaply, because the server can keep a ready-made copy and send it again and again.

A registration cannot work that way. Each one is unique work the server cannot skip: checking places, saving the details, taking the payment and sending the confirmation.

When hundreds of families submit within the same few minutes, that work arrives faster than the server can finish it. Requests queue, the queue grows, and new ones are turned away.

Where the work piles up

Each registration passes through several steps, and each step has its own limit:

The payment step is the slowest. While the server waits for the card processor, each registration holds on to part of the server, and the waiting adds up.

The limits of an ordinary hosting plan

Shared hosting plans cap how many processes a site may run at once, how much memory it may use and how many emails it may send each hour.

Those caps suit the rest of the year, when a club's site has a handful of visitors at a time. In the busiest ten minutes the site hits every one of them.

When the email cap is reached, confirmations wait or are refused, and parents who paid hear nothing. Many assume the registration failed and try again.

Estimating the load

Start with the families: last session's registrations, the waiting list, and anyone new you expect. Then count the pages and submissions each one goes through to finish.

When places are scarce, most families arrive in the first few minutes. Multiply families by steps, squeeze the total into those minutes, and that is the load to plan for.

A developer can turn that into requests per second and compare it with what the hosting can handle.

Testing before the day

A load test uses software to imitate many parents registering at once, on a copy of the registration system or on the real one before opening, with test records.

It shows where the system slows, where it fails and what parents would see. After each change the test runs again, until the busiest ten minutes pass cleanly.

Tell the host first. Some plans forbid heavy testing without notice, and the host may want to watch its own servers while it runs.

A worked example

A ski school on a mountain near the city runs eight-week Saturday and Sunday programs for children, and registration for the winter opens on one evening in October.

Last October the site slowed within a minute of opening and stopped for most of the first hour. Some parents were charged twice, others not at all.

The developer found registration running on the same shared plan as the rest of the site, with every step done at once and three emails sent per family.

This year family accounts open in September, so children's details and consent forms are done before opening night. On the night itself parents only choose a program and pay.

Registration moves to hosting with room set aside for October. The card processor's own page takes payment, emails go out from a queue, and age groups open on separate evenings.

A load test at the expected numbers is booked for September. The plan rests on each family bringing less work on the night, spread over two evenings, to a server with room for it.

A setup sized for the peak

The right setup depends on how many families arrive and how scarce the places are, and usually combines several measures.

Extra server capacity for registration week, a system that puts parents in an orderly line when busy, and opening times staggered by program all spread or absorb the load.

Moving work out of the peak helps most: accounts and details collected earlier, payment on the processor's own page, confirmations sent a few minutes later.

What parents see when it is busy

Even a well-sized system can be slow for a minute. A plain message saying the site is busy and the place is held is far better than an error page.

The pay button should switch off after one press, so a second tap cannot charge a card twice. Every completed registration needs a confirmation page that parents can screenshot.

Explain the process beforehand, by email and on the site: what time, what to have ready, and which number to ring if a payment fails.

The counter-case

A club with plenty of places, whose families register over several weeks, will never see this. The problem exists only when scarce places are released at a single moment.

Some clubs avoid the rush altogether by changing the policy: priority for returning members, or a draw for places among everyone who applies by a date.

That is a club decision rather than a technical one. Where places are first come, first served, the setup has to be sized for the busiest ten minutes, not the average day.

Ready for the first ten minutes

  1. Count the families likely to arrive in the first minutes.
  2. Map each step a registration goes through.
  3. Ask the host about limits on processes and email.
  4. Move accounts and details ahead of opening day.
  5. Run a load test at the expected numbers.
  6. Disable the pay button after one press.
  7. Tell parents exactly how opening time will work.

Step five alone shows what will happen before parents find out. A test that fails in September costs an afternoon; a failure in October costs a week.

A quieter problem, parents leaving a registration form partway through, shows up in a goal funnel, as the registration form where parents give up describes.

Frequently asked questions

Why does the site fail only on registration day?

Reading pages is cheap because servers can resend ready-made copies. Each registration is unique work, and on opening day hundreds arrive within the same few minutes.

How do I estimate the load?

Count the families likely to register, the pages and submissions each one goes through, and the few minutes in which most arrive. A developer can compare that with the hosting.

What is a load test?

Software that imitates many people registering at once, run on a copy or before opening, to show where the system slows or fails. Tell the host first.

Why do some parents get charged twice?

They press the pay button again when the page stalls. The button should switch off after one press, and every completed registration should show a confirmation.

Will a bigger hosting plan solve it?

It helps, but moving work out of the peak often helps more: accounts and details collected earlier, payment on the processor's page, confirmation emails sent later.

Do small clubs need any of this?

Only when scarce places open at one moment. A club whose families register over several weeks rarely sees a rush the server cannot handle.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Registration opening on a set day this fall?

Tell us when it opens and how many families you expect, and we will check whether your setup can take the first ten minutes.

Start a Conversation