THE BLOG
11/13/2013 06:40 pm ET Updated Jan 23, 2014

Obamacare Website's Upcoming Spike

The first figures are out for the number of people who have successfully used the Obamacare website to buy insurance, and it is no surprise to anyone by now that they fell far short of the expectations drawn up before the website's launch. The website is undergoing intensive repair efforts, with the target of being up and running for most users by the end of this month. Doubts exist as to whether that target will be met, but there's a whole lot of wiggle room in that word "most," so undoubtedly both sides will spin whatever happens to present it in the worst or best light possible. But what few seem to be talking about is what will happen next -- in the first two weeks of December. Which could be even worse than the initial rollout, as hard as that is to believe.

The website's problems fall into two main categories. There are performance problems and there are functional problems. The functional problems are bugs in the design (or programmatic coding) where the site doesn't do what it is supposed to do. These are often tough to fix and may require extensive rewriting of the software, sometimes from the ground up. The Obama White House says they are making progress on fixing these, and I've heard that "six out of ten" such problems have been addressed. This isn't too bad a number, and seems to be at least reasonably on track to hit their end-of-the-month deadline to fix most all of the problems (or at least the biggest ones).

But the performance problems should be seen as extremely worrisome, at this point, for anyone rooting for the website to succeed (or even "work as designed"). Performance problems can often be fixed easily (if expensively) by just "throwing more servers at the problem." Adding hardware to improve the ability to handle more simultaneous use is a fairly easy fix, as these things go (although, as mentioned, it can get expensive when you need to add hundreds of servers to fix the problem).

But creating an enormous server farm (yes, that actually is the correct term) only works as well as the software that performs the "load balancing" which directs the incoming traffic to different servers. And it sounds like the load balancing part of the software is as bad as the rest. From a story in the Washington Post today:

The insurance exchange is balking when more than 20,000 to 30,000 people attempt to use it at the same time -- about half its intended capacity, said the official, who spoke on the condition of anonymity to disclose internal information.

What this means is that the fairly simple expedient of throwing servers at the problem has not worked. And this is not just troublesome for the system right now, it could lead to absolute disaster in the first weeks of December.

To understand the danger, take a look at a chart displaying the signup rate when Massachusetts started up what we now call "Romneycare" (this chart is featured in another Washington Post article, but due to copyright reasons I can't reproduce it here, sorry).

See that gigantic spike? The number of people signing up was fairly consistent right up until the mandate kicked in, and then it almost tripled for that month. This is the problem the Obamacare website is about to face, except on a much larger scale. It will be the difference between a leisurely walk around a shopping mall the day before Thanksgiving and fighting the consumer hordes the day after Thanksgiving when the "Christmas shopping season" starts. That is the magnitude of the traffic problem waiting in the wings for the Obamacare website.

When the Obamacare website launched, millions of people went to browse it and sign up for insurance. But it soon became apparent that the site wasn't working all that great, and we've had a steady drumbeat in the media since then about how broken the site still is. This has, without doubt, meant that millions of people have put off using the website. Why bother, if the dang thing's broken, right? These people are patiently waiting for an announcement that the site is now functioning, after which they will return to the website to try again. But that's only one group of people. There's another -- far larger -- group that has not checked out the website at all, and is waiting until the last minute. Procrastination is a downright American sport, when you think about it.

Both these groups are going to swamp the website, beginning very soon. My best guess would be for an enormous traffic spike to begin the weekend after Thanksgiving, when many are off work and have spare time, and are thinking about family and the upcoming deadline of December 15. If you don't sign up for insurance before this date, then you will not have insurance on the first of next year, so millions will be attempting to purchase insurance from the day after Thanksgiving right up to the deadline. There's a bigger deadline at the end of next March, but the December spike is the one staring us in the face right now.

Figuring the specification for how many people should be able to simultaneously use a website is guesswork, to a large degree. But if 20,000 to 30,000 simultaneous users are only half of the specification in the first place, then what is going to happen when the spike hits? If the system had worked from the beginning, then maybe the specification of 50,000 or 60,000 simultaneous users might have been adequate. But since the system hasn't been working for two months before the spike, there will be a pent-up demand of people who are waiting for the green light from the White House in addition to all the "wait until the last minute" folks. What happens if this triples the traffic, as happened in the Massachusetts example? The system might need to continue functioning with as high as 150,000 to 200,000 users at the same time -- which is far beyond the original specification, and even farther beyond the 20,000 to 30,000 overloading the system as it stands.

Most who don't really understand technology (sadly, this includes most of the mainstream media) have been speaking of the Obamacare website as if it only had two possible states: "broken" and "working." The truth is a little subtler than that. If the functional bugs are fixed, then the site is technically working correctly, but if the traffic overloads continue to be a big problem then users are still not going to be able to effectively use it. Right when that huge wave of traffic will be about to crest.

This could be a political disaster in the making -- a separate disaster than the initial rollout. Because the Obama White House is going to attempt to tell the public "it's working pretty well for most people" (in some form or another) at the end of November. They pretty much have to, at this point. But when they do -- when they flash that green light to the public -- there is going to be an absolute stampede to log on to the website as a direct result. If this spike freezes the system for the first two weeks of December, then people are going to become not just frustrated but enraged. It will no longer be a matter of: "Well, I can sign up now or I can sign up in a few months," it will instead be: "My family will not be medically insured come January, because I cannot access the site."

The Obamacare website launch will go down in history as one of the worst technological rollouts ever. It will be studied in textbooks by computer science majors for years, one assumes, as a prime example of what not to do. The Obama White House has promised that the site will be fixed and working by the end of November. They may technically achieve this by fixing all the major functional bugs so the software at least performs as designed. But if what follows is such a spike in traffic that it (once again) brings the website to its knees, then all the spin of how many bugs were fixed isn't going to matter at all -- because the storyline is still going to be: "Obamacare website still hopelessly broken."

I would hope that someone at the White House has at least looked at that chart from Massachusetts, and is aware of the inevitable upcoming spike in traffic. I would hope that someone has brought up the issue that perhaps the specification for simultaneous users is going to be woefully inadequate when the stress test of that spike hits. But, at this point, I wouldn't bet money on it.

 

Chris Weigant blogs at:

ChrisWeigant.com

Follow Chris on Twitter: @ChrisWeigant

Become a fan of Chris on The Huffington Post