3 ms·
Compare this with the medicaid "part D" government website launched in 2006. It was designed around an anticipated load of 20,000 simultaneous users so they sca
by InclinedPlane 13y ago
Compare this with the medicaid "part D" government website launched in 2006. It was designed around an anticipated load of 20,000 simultaneous users so they scaled it to be able to serve 150k users. Anyone who builds websites in 2013 without understanding the spiky nature of traffic or the necessity to build in capacity overhead is incompetent, end of story.
The amount of money spent on building healthcare.gov (many millions) just makes that incompetence even more infuriating.
- dangrossman 13y agoBeing handed impossible constraints (serve 250k simultaneous users, verify them all with the IRS, but the IRS service you have to talk to can only handle 1000 simultaneous requests) isn't incompetence on the developer's part, and we don't know whether something like that isn't what's happening. The team that built this site (which has had no unintentional downtime, latency or server errors -- whatever code they wrote hasn't fallen over, it's just stranded most people on a "please wait" page when they try to register) has no power over systems at all the other agencies they have to work with.
- InclinedPlane 13y agoImpossible? That's just a constraint. If you have a dependency on some other service that is highly rate limited then you work around that, using any one of a kajillion different techniques. You don't just drop everything on the floor, throw up your hands and blame everyone else.