3 ms·

The answer is that you can't structure the transaction as a realtime query. You have to structure it as something that's sent and gives you a ticket, and the re

The answer is that you can't structure the transaction as a realtime query. You have to structure it as something that's sent and gives you a ticket, and the reply associated with that ticket will come back in its own time. Stick the processing pipeline in Twitter Storm (which can retry any step until the whole pipeline is done) and structure the requests as nearly-idempotent (so a repeated reply is harmless, and the first arrival associated with the ticket wins). Finally, you have an "inbox" where people can wait for and see their answer, with optional SMS and email notification.

hga 13y ago
Interesting, but at some point people have to be shown a selection of offerings. That selection must allow seeing if your doctors are in the network. Your suggestion would allow for that, but not I sense in the "instant gratification" way we're used to dealing with web sites. I.e. "thanks for your input, wait for SMS/email/N hours till you log in again for the next step". BTW, I've read it's a 30 step process. Not all will require "take a ticket and wait to be called", but more than 1 or 2 I suspect.
- JulianMorrison 13y ago
  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.
- integraton 13y ago
  It's not delivering instant gratification now. More importantly, it's very standard practice to do asynchronous jobs and notify users on completion, as seen in the data export or input features on many web services. Whether users get results immediately or need to be notified is a UX issue, and a requirement that the entire system be designed to deliver results immediately sounds exactly like the kind of speculative, unconventional UX requirement that non-UX people come up with around a conference table.

hga 13y ago

Interesting, but at some point people have to be shown a selection of offerings. That selection must allow seeing if your doctors are in the network. Your suggestion would allow for that, but not I sense in the "instant gratification" way we're used to dealing with web sites. I.e. "thanks for your input, wait for SMS/email/N hours till you log in again for the next step". BTW, I've read it's a 30 step process. Not all will require "take a ticket and wait to be called", but more than 1 or 2 I suspect.

JulianMorrison 13y ago
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.
integraton 13y ago
It's not delivering instant gratification now. More importantly, it's very standard practice to do asynchronous jobs and notify users on completion, as seen in the data export or input features on many web services. Whether users get results immediately or need to be notified is a UX issue, and a requirement that the entire system be designed to deliver results immediately sounds exactly like the kind of speculative, unconventional UX requirement that non-UX people come up with around a conference table.