8K transactions / second is hardly extreme load. It's good they can support it, and I doubt they need more, but many, many sites handle more load than that.
I will say that if the system scales well horizontally the important metric is how many resources you need to achieve that amount of transactions.
If they used 70 4-core m3.xlarge that means that they can attend 114 transactions/second per 4-core server. And that looks slow without more data about what are the requirements for the login process.
But if you look at the peak of 150 requests per second, then probably it will cost more money to improve the performance than to actually just add servers.
At work we have over 1 billion users. But as it scales horizontally the relevant number is how many memory/disk database instances do you have. The same applies to the application layer for the number of transactions. In fact the development servers are slower than the live ones even that they have just tens of thousands of users.
For our amount of users/transactions tuning for performance saves lots of money. So it makes sense to improve the code on that measure.
For comparison, when I received the RFP for the Italian and the British (gov uk verify) national authentication systems.
The numbers that were asked for were 12k/auth per second during peak time for the Italians.
The British wasn't clear but it hinted at 0.1% of user authenticating per second, which is about the same range. (The numbers of users itself was not defined, it depends on who would join the program).
SLA: 1500 ms for the account verification. 150 ms for most operations. (Some more time when requesting optional attributes like name/address/phone)
To be fair, a "transaction" here is probably a lot more complex than people give credit. Healthcare is a very sophisticated beast... it's a huge many to many problem, and though people keep trying to "standardize" details always prevail.
Most sites are more complicated than they seem from the outside. Complexity is fractal -- the closer you get to something, the more complex it is.
One of my past employers was Salesforce.com. Seems pretty simple at first glance (and the early implementations were very simple), but then you learn more. Ignoring all of the platform-related stuff, just doing a multi-tenant database at scale turns out to be plenty hard.
The fact remains, they're a couple orders of magnitude away from extreme load.
I know it's just a throw away joke, but this persistent idea that government is incompetent, no matter what is really damaging.
When it comes to health care systems there is no evidence whatsoever that less government means more efficiency, if anything the US is a huge example to the contrary.
Im not really joking, their ability to do anything efficiently or correctly for a reasonable sum of money is embarrassing. I know it's a joke as well, but it's funny because it's true.
My experience is the opposite. Private companies seem completely inefficient compared to government, and I've worked as engineers in both.
Really it is only a right-wing profit-driven talking point to say government is inefficient, mostly to protect against their profits that government takes away.
Uhh, the US has had extreme government regulations regarding healthcare for as far back as I remember. Every state has it's own insurance administrator and purchasing insurance across state lines isn't allowed. What we have right now is the worse of both systems actually. It's a heavily regulated false free market where the customer has basis for comparing prices and has no direct control over providers. Instead they must choose between a government chosen option or an employer chosen one. It's just terrible all around.
With a single payer system, at least it would be fair to lay all blame on the single payer. It'd still be beuqacratic and political, but at least there'd be direct responsibility.
Removing the regulations, at least the customer would be able to choose a provider themselves and people could sue over pricing disagreements. There would be issues with pre-existing conditions and low income that would still need to be addressed, though.
Either option is better than where we are today, which is, well I'm not sure. There's not really a term to define the mess we've created. It's not socialist, it's not capitalist, it's just a mess of special interests, political concessions, and reactionary legislation. I guess the one thing we can definitely call it is bureaucratic.
And is Healthcare.gov developed by the government or just bough to an external company? It just an observation, I don't know if Healthcare.gov is a good or bad technology.
Not quite. It was designed by a contractor, developed by several others, and once it was released to the public and shown to be dreadful, another contractor was put in charge of fixing it. It's still primarily developed by contract to this day.
The first head of the USDS was involved in coordinating the fixing of Healthcare.gov, though.
If they used 70 4-core m3.xlarge that means that they can attend 114 transactions/second per 4-core server. And that looks slow without more data about what are the requirements for the login process.
But if you look at the peak of 150 requests per second, then probably it will cost more money to improve the performance than to actually just add servers.
At work we have over 1 billion users. But as it scales horizontally the relevant number is how many memory/disk database instances do you have. The same applies to the application layer for the number of transactions. In fact the development servers are slower than the live ones even that they have just tens of thousands of users. For our amount of users/transactions tuning for performance saves lots of money. So it makes sense to improve the code on that measure.