2013-10-05

Some brief questions for the architects of healthcare.gov

There are various theories bouncing around about why the HealthCare.gov website is having such problems with capacity:

One possible cause of the problems is that hitting "apply" on HealthCare.gov causes 92 separate files, plug-ins and other mammoth swarms of data to stream between the user's computer and the servers powering the government website, said Matthew Hancock, an independent expert in website design. He was able to track the files being requested through a feature in the Firefox browser.
That's not very promising. You'd somewhat hope that one of the pivot actions of a website was as lightweight as possible from the client side; there are going to be enough problems with the server persisting everything into its database. The page from which you apply should have as much of the JavaScript already loaded (and appropriately marked as cacheable so it's not re-loaded when the page changes). Loading everything in the time-critical period when you're trying to lock a table (and I bet they're not row-level locking) in the database to write the user application is asking for trouble.

Anyway, that's just speculation. But here are the questions for the HealthCare.gov folks:

  1. How many concurrent users did you determine you could support on the system with the resources at launch?
  2. What were the system bottlenecks that imposed that limit?
  3. What were your contingency plans to add resources to temporarily raise system capacity as required at launch?
  4. What was your estimate of visitor traffic to the site on launch week, based on the anticipated heavy country-wide publicity?
  5. What performance degradation did you anticipate when 2x and 10x the maximum users attempted to use the site?
  6. What plan did you have to divert users by geo-located IP and / or run the system in a degraded mode in the event of overload, to focus the available performance on people who might actually want to buy healthcare?
  7. If you hadn't done the performance and load testing to determine the above numbers and evolve the above plans before launch, would you care to explain why not and what you thought you were being paid to do?
In short; did you determine in advance when and how the system was going to fall over with the traffic you were going to get and how to get it back on its feet, and if you didn't then why not?

If the Senate is looking for questions to ask the HealthCare.gov architects when the inevitable reprisals come around, they could do worse than start with these.

No comments:

Post a Comment

All comments are subject to retrospective moderation. I will only reject spam, gratuitous abuse, and wilful stupidity.