3 ms·

> synchronous requests impact the availability of your service, because all the invoked services must be up and running in order for your service to work. The m

by mrkeen 2y ago

> synchronous requests impact the availability of your service, because all the invoked services must be up and running in order for your service to work. The more services you rely on in a synchronous manner, the lower the availability of your service will be. Hear, hear. And the knock-on effect is that as a developer you end up with more support tickets (because downstream services are always screwing up in some way), and your users will make it your problem. Worse yet, once you've diagnosed the problem (partner company returned 500 for a while) and fixed it (well you probably can't fix it! The codebase belongs to a different company!), you might be stuck sheepishly asking the user to try again, because the sync control flow (including auth) starts from the user. Had the system been built async, then the user would have created an (auth'd) request in your system, at which point you and your system can decide on your own retry policy, since you own the control flow. If the request is reified in a queue/ledger as data (rather than being represented implicitly by services invoking one others' methods directly) you can start automating/batching your support actions. You can query "how many Requests created more than 24h ago are not married to a successful Response" and bulk-fix by re-attempting fulfillment of those Requests. Furthermore, you might start discovering your system is a little crashier than you thought. Maybe for every Karen who calls into customer support and tells you to fix her issue, there are 19 other users who got a 500 and just got on with their day, (but probably won't renew their subscription to your service 3 months from now.)

sunrunner 2y ago
> you might be stuck sheepishly asking the user to try again, because the sync control flow (including auth) starts from the user. How does this actually work in practice? At some point you need to communicate the results of a successful or failed login attempt to the user (more generally, the initiating party) which means they're inherently waiting for something and will either see a success or a failure. A login as a precursor event to other kinds of actions feels inherently synchronous, because it's not a fire-and-forget action.
- mrkeen 2y ago
  What I said about batched handling of support cases probably doesn't apply to logins - you're not going to 'fix' a login in time for it to be useful. Yes, the user is waiting for their login to return, so it will feel synchronous to them. ( As some background, BankID is the de-facto auth service here. In its previous form, you typed your personal number in, and you'd get a popup on your phone where you'd enter your pin. They made the flow more secure by displaying an animated qr instead of typing in your personal number. Here's the new flow as used by the Tax Office: https://m01-mg-local.auth.funktionstjanster.se/mg-local/auth/ccp5/grp/this https://m01-mg-local.auth.funktionstjanster.se/mg-local/auth... Swedbank didn't get the memo and is still using the old flow: https://online.swedbank.se/app/ib/logga-in https://online.swedbank.se/app/ib/logga-in ) Check out the BankID flow charts: https://developers.bankid.com/getting-started/use-cases https://developers.bankid.com/getting-started/use-cases. If you're a small business integrating against BankID, it probably doesn't matter if each iteration of the backend<->bankid /collect loop uses its own thread (sleeping for 1-2s each time). But at BankIds scale there's no way they'd be maintaining a separate thread of execution for each user, it would need to be batched.

by mrkeen 2y ago

sunrunner 2y ago

> you might be stuck sheepishly asking the user to try again, because the sync control flow (including auth) starts from the user. How does this actually work in practice? At some point you need to communicate the results of a successful or failed login attempt to the user (more generally, the initiating party) which means they're inherently waiting for something and will either see a success or a failure. A login as a precursor event to other kinds of actions feels inherently synchronous, because it's not a fire-and-forget action.

mrkeen 2y ago
What I said about batched handling of support cases probably doesn't apply to logins - you're not going to 'fix' a login in time for it to be useful. Yes, the user is waiting for their login to return, so it will feel synchronous to them. ( As some background, BankID is the de-facto auth service here. In its previous form, you typed your personal number in, and you'd get a popup on your phone where you'd enter your pin. They made the flow more secure by displaying an animated qr instead of typing in your personal number. Here's the new flow as used by the Tax Office: https://m01-mg-local.auth.funktionstjanster.se/mg-local/auth/ccp5/grp/this https://m01-mg-local.auth.funktionstjanster.se/mg-local/auth... Swedbank didn't get the memo and is still using the old flow: https://online.swedbank.se/app/ib/logga-in https://online.swedbank.se/app/ib/logga-in ) Check out the BankID flow charts: https://developers.bankid.com/getting-started/use-cases https://developers.bankid.com/getting-started/use-cases. If you're a small business integrating against BankID, it probably doesn't matter if each iteration of the backend<->bankid /collect loop uses its own thread (sleeping for 1-2s each time). But at BankIds scale there's no way they'd be maintaining a separate thread of execution for each user, it would need to be batched.