How to build the vaccine registration system – Don’t!

• Eliminate need to register online, eliminate problems with online registration system
• Redistribute load - open registration by criterion ie age, sex, geography, last 4-digits of IC

After the entirely predictable meltdown of the Malaysian vaccine registration website on Wednesday, the hashtag #AstraZeneca ended up trending for all the wrong reasons as the rakyat vented their frustrations online at the Hunger Games-esque situation that the opt-in registration channel created. What should’ve been a celebration of 1 million people getting registered for their doses, turned into criticism and baying for blood.

Keeping in mind that all this happened on the holiest day in the Buddhist calendar, we should all take a collective deep breath, remain calm and take a detached look at the situation. While I think that the situation was an entirely avoidable one, I applaud any and all government effort to get us vaccinated as soon as possible.

A lot of criticism has been levelled at those who built the website and there are calls for the minister to reveal who was responsible for this debacle. Also, there is no lack of ‘experts’ who are providing technical suggestions on social-media, to help improve the design of the registration system – from improving the front-end user-experience to the back-end architecture.

I can argue the merits of caching, scaling, sharding, and even proffer suggestions on optimisation. But since I am not privy to the internal constraints that the development team faces, I will not pretend to know what the best technological solution is. Instead, I offer that any technological solution will eventually succumb to human nature, specifically our uniquely Malaysian nature.

Although I am a computer engineer by training and profession, I am quite a ‘lazy’ one. Personally, I try to avoid doing real engineering work and instead, I try to find solutions that are the least technological in nature. If the problem can be solved without building another App, deploying another back-end, or using another block-chain, even better! Less is more.

Someone in one of my many WhatsApp groups mentioned that the system must not have been tested for the expected load. I asked what is the ‘expected’ load. 33 million may seem like a reasonable number, seeing that it is our population size. But when we start hammering the site with every single device that we are able to get our hands on, with the help of every relative and friend who was available at the time, I cannot really blame the developers for not testing against human ingenuity.

Consider, in the first round of registrations on 2 May when 268,000 doses got snapped up in less than 3 hours. That is about 89,300 doses an hour. So, if the update last night by the Covid-19 Immunisation Task Force (CITF) that all 959,609 doses allocated for this round of registrations got snapped up in an hour is accurate, it shows that a significantly larger load was already anticipated and steps had already been taken to remediate.

In school, I was taught that the first step to solving any problem is ‘problem definition’. If we do not identify the right issue, we will bark up the wrong tree. While it is easy to blame the developers as incompetent and tempting to throw more money and technology at the problem, I would consider an alternate approach because I do not see this as a technological problem.

I feel that we should tackle the issue even before anyone visits the front-end website. Instead of trying to tackle the human stampede by deploying more infrastructure, I would first consider redistributing the load. This can be done by opening registration according to some criterion e.g. age, geography, gender, last-digit of their NRIC, etc. Since the government has all our census data, they know the best way to divide up the population into manageable numbers.

We could take the system used by the NHS to register vaccinations in England, as an example. Online registration was opened to people by age groups. While they first started vaccinating senior citizens, they gradually lowered the limit for online registration to those 40 and older across April, then to those 30 and older across May. Their target is to give everyone at least one dose by end of July.

In terms of the user experience, when a person attempts to register, they are given a queue number, shown their position in the queue, the estimated wait time, and given the option to stay in line or try again later. This visual feedback is certainly better than our system of silently failing, with error codes only visible to those who know how to use the developer’s console.

Also, their site does not require anyone to smash the browser refresh button repeatedly while praying to the gods and cursing whomever developed the system in the same breath. That queue page has a back-off and retry mechanism built-in. While a person waits for their turn, they can continuously monitor the queue number and wait times without hitting refresh. Eventually, the system displays the form that they can fill to get their appointment.

In addition, people can also get an appointment through their GP. This is a legitimate question that lingers in my mind. Our private sector hospitals and clinics have volunteered to become vaccine centres months ago. Many are ready to deploy but only a small number are operational. I wonder why we have not fully utilised this available resource to step up the number of vaccinations.

It is obvious that the website succumbed to the load because people want the vaccine, especially with ICUs buckling under pressure. We can significantly increase the reach of our vaccination programme if we employ more hospitals and especially clinics in smaller towns and villages, instead of building ‘Super PPVs’. When you build a distributed/decentralised system, it scales better than a centralised/monolithic system.

People should be able to just make an appointment with their GP to get the vaccine, instead of having to register online. If we eliminate the need for people to register online, we eliminate all problems with any online registration system. There will be no need to point fingers at the developers nor argue about how best to build the system to handle the load. Eliminate the load.

There I go, redefining the problem to the PICK (the Malay language acronym for the National Covid-19 Immunisation Programme) process instead. But that is a big issue that is well beyond my word-count. So, I’ll leave that to those who are better suited to such things than myself.

Ir Dr Shawn Tan is a registered chartered & professional engineer who has been programming since the late-80s. A former lecturer and research fellow, he minds his own business at Aeste while working on his magnum opus. He designs open-source microprocessors for fun. He can be reached via Twitter as @sybreon.