{
    "href": "/post/2013/10/03/untangling-obamacares-web-glitches/",
    "relId": "2013/10/03/untangling-obamacares-web-glitches",
    "title": "Untangling Obamacare's Web Glitches",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/government/",
            "relId": "government",
            "title": "Government",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/health-care/",
            "relId": "health-care",
            "title": "Health Care",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2013-10-03 09:37:39 UTC",
    "updated": [
        "2013-10-03 09:37:39 UTC"
    ],
    "html": "<blockquote>\n<p>What the heck could be going on? My friend stated the obvious: \u00e2\u0080\u009cIt's clear that they're getting more traffic than they can handle. The question is why they can't handle the traffic they're getting.\u00e2\u0080\u009d Load problems could explain servers hanging in California and New York \u00e2\u0080\u00a6 but the drop-downs? The standard explanation for this is \u00e2\u0080\u009chigh load,\u00e2\u0080\u009d but high server loads don\u00e2\u0080\u0099t cause your security dropboxes to empty out.</p>\n<p>\u00e2\u0080\u009cThe drop-down thing is mystifying,\u00e2\u0080\u009d he told me. If federal exchanges decided to populate the security question fields by calling up a list of possible questions from another server -- one that didn\u00e2\u0080\u0099t have a lot of capacity -- then that might be causing the sign-up process to stall at that step. For an application that expects a lot of traffic, this is a very bad idea.</p>\n<p>\u00e2\u0080\u009cJust cache them on the front ends, for heaven's sake, so you only need to ask once,\u00e2\u0080\u009d he said. \u00e2\u0080\u009cA database call to get questions shouldn't be in the critical serving path. If you're hitting the database just to load the security questions, then just serving individual pages is going to be expensive.\u00e2\u0080\u009d</p>\n<p>The various glitches, he pointed out, \u00e2\u0080\u009ccould very easily be because deadline pressure caused them to take some shortcuts that impacted their ability to scale.\u00e2\u0080\u009d</p>\n<p>Such as?</p>\n<p>\u00e2\u0080\u009cThe aforementioned let's-hit-the-database-for-security-questions thing.\u00e2\u0080\u009d</p>\n<p>Why would they use such a seemingly obvious poor design?</p>\n<p>\u00e2\u0080\u009cIt can be easier to make a call to another server to get something when you need it than to implement a cache that you prepopulate either from static files or from the database on startup. Making a call to another server is also something you'd naturally think to do if you hadn't had to focus on scalability before. The security question page is probably not the thing you're most concerned about, so you give it to the new hire to do as their starter project. They don't know what they're doing, so they implement it the straightforward way \u00e2\u0080\u00a6 and since you're under unbelievable deadline pressure to get something working now nobody reviews it in detail.\u00e2\u0080\u009d</p>\n<p>Obviously, we don\u00e2\u0080\u0099t know if this theory is correct -- but it does fit the particulars.</p>\n</blockquote>\n<p>Government programmers are subject to the same development pressures as the rest of us. Via <a href=\"http://www.bloomberg.com/news/2013-10-02/untangling-obamacare-s-web-glitches.html\">Untangling Obamacare's Web Glitches - Bloomberg</a>.</p>\n"
}
