3 ms·

Well, they aren't getting instant gratification now, are they? I suspect a lot could be cached - that is you take a list of questions up front, what comes back

Well, they aren't getting instant gratification now, are they? I suspect a lot could be cached - that is you take a list of questions up front, what comes back from the "ticket reply" contains any further questions you'd need to answer and enough canned data to process the replies immediately. So you wouldn't need to take a ticket more than once. But even if you did need to, at least it would be something people could fill in and walk away from. They wouldn't be kept around, drumming their fingers and worrying about being late to work.

hga 13y ago
"Well, they aren't getting instant gratification now, are they?" Indeed! But I was referring to the initial architecture of the site. E.g. the March objective, “Let’s just make sure it’s not a third-world experience.” expressed by Henry Chao, CMS CIO, who in theory should have been in the front lines. Sigh, I bet he was, knew what was coming but didn't have the authority to make it work, or as you implicitly suggest, down-grade the architecture/expectations into something that might possibly work in the time left. And then there's the last minute (well, month) change to requiring a heavy duty, validated up the wazoo registration before doing anything. Doubt they could have made that work in less than 2 months ... maybe. This was needed, but at lower transaction rates, e.g. otherwise window shopping would allow a lot of people to see they couldn't get a better deal through the exchange (e.g. no subsidies for you, which only the federal system is allowed to calculate). Suppose prior to that they arranged for "X rate of idempotent reads" with e.g. the IRS, and now they need a 10/100/1000X rate, meaning they should have cached everything that doesn't change quickly. Almost certainly too late to do it by then. My, my, years from now this is going to be one of the most significant case studies in project development.
viscanti 13y ago
Queues solve some problems. Others that are read heavy, but rarely updated (queries for which Doctors are on the system) can be cached and read from slaves. Problems that benefit from being async should be async, those that aren't shouldn't. It's usually pretty easy to do both in a system.

hga 13y ago

"Well, they aren't getting instant gratification now, are they?" Indeed! But I was referring to the initial architecture of the site. E.g. the March objective, “Let’s just make sure it’s not a third-world experience.” expressed by Henry Chao, CMS CIO, who in theory should have been in the front lines. Sigh, I bet he was, knew what was coming but didn't have the authority to make it work, or as you implicitly suggest, down-grade the architecture/expectations into something that might possibly work in the time left. And then there's the last minute (well, month) change to requiring a heavy duty, validated up the wazoo registration before doing anything. Doubt they could have made that work in less than 2 months ... maybe. This was needed, but at lower transaction rates, e.g. otherwise window shopping would allow a lot of people to see they couldn't get a better deal through the exchange (e.g. no subsidies for you, which only the federal system is allowed to calculate). Suppose prior to that they arranged for "X rate of idempotent reads" with e.g. the IRS, and now they need a 10/100/1000X rate, meaning they should have cached everything that doesn't change quickly. Almost certainly too late to do it by then. My, my, years from now this is going to be one of the most significant case studies in project development.

viscanti 13y ago

Queues solve some problems. Others that are read heavy, but rarely updated (queries for which Doctors are on the system) can be cached and read from slaves. Problems that benefit from being async should be async, those that aren't shouldn't. It's usually pretty easy to do both in a system.