01 — The situation
Three kinds of user, each wanting something different.
Our client runs paid vaccination programmes for organisations — companies, government offices, and associations register their staff in bulk. The events move from city to city, and each one has its own capacity, its own pricing, and its own clinic carrying it out.
One system has to serve three parties at once:
- Participants — registering and paying from a phone, usually outside office hours.
- Clinical staff — filling in medical records at the venue, on their feet, quickly, on whatever signal they can get.
- Operators and organisations — watching capacity, group invoices, and the reports that follow the event.
02 — The problem
Load that piles up, not load that is large.
A system with a thousand users a day is easy. A system with a thousand users in one hour, in one building, over one shared network — that is an entirely different problem.
On event day everything happens at once: participants queue while refreshing the page, clinical staff save one record after another, and consent signatures are drawn straight onto a phone screen. If any one part slows down, the physical queue at the venue grows with it — and what's waiting isn't a number on a dashboard, it's a person standing up.
Three things break this most easily:
- Duplicate participants. One person registered twice — once by themselves, once by their employer. Capacity is consumed by a phantom, and the invoice doubles.
- Capacity overrun. The number of doses carried to the venue is fixed. Over-registration means someone travels there and leaves empty-handed.
- Heavy work blocking the screen. Receipts, certificates, and emails — done at the moment a button is pressed, they make the participant wait.
What's waiting isn't a number on a dashboard. It's a person standing at the venue.
03 — What we did
Designed for the worst day, not the average one.
Five decisions settled it, and all of them were made before a single line was written.
- 01
Heavy work moved off the screen
Receipts, certificates, and emails are not produced when the button is pressed — they go into a queue and are handled by a separate worker. The participant gets an answer immediately; the document follows seconds later. This single change did more for event-day speed than anything else.
- 02
Capacity with a buffer, not capacity to the last seat
Each event has a participant limit plus a small buffer above it. The reason isn't technical, it's practical: someone always cancels at the last minute, and someone always turns up without registering. That buffer is what keeps operators from turning people away at the door.
- 03
Duplicate screening at two points
The identity number is checked when a participant registers themselves, and checked again when an organisation uploads a staff list in bulk. Two ways in, two filters — because a single filter at a single point can always be walked around from the other direction.
- 04
Medical records designed for a phone in the field
Not a shrunken desktop screen. Short forms, large buttons, and the questions that rarely change already filled in. The consent signature is drawn directly on the screen and attached to the participant's document immediately, along with a verification code so the document can be proven genuine.
- 05
Tested on site, on participants' actual phones
The final testing wasn't done from the office. We measured it at the venue, on participants' devices, over the mobile network they were really using. Numbers that come off a developer's laptop are always too good to trust.
04 — The outcome
Not one outage so far.
Since launch the system has carried many events across different cities without once stopping. Page load times hold between one and five seconds — and that isn't a figure from a monitoring tool, it's measured directly on the phones of participants standing in the queue.
Operators can open per-event reports without waiting for a manual reconciliation, and organisations receive group invoices whose totals match the number of people who actually attended.
We still look after the system today, and it keeps growing as the programme does.
05 — What keeps it standing
The decisions you can't see from outside.
Looked at briefly, there is nothing remarkable here — a registration form, a payment page, and a medical record form. What keeps it standing is precisely the part you can't see.
We refuse to compute anything live on the screen. Every expensive number — remaining capacity, invoice totals, report summaries — is prepared ahead of time and stored, not recalculated on every page view. On an ordinary day you would never notice. On event day it is the difference between a queue that moves and a queue that stops.
We assume the network will be bad. Every important action is safe to repeat — if clinical staff press save twice because the screen was slow to respond, the result is one record, not two.
We decided who may see what at the start, rather than patching it in later. A clinic sees only its own participants, an organisation sees only its own staff, and identity data is masked out of any report that doesn't need it.