the internet banking example you suggested is asynchronus by its nature, since two sites are involved in the workflow. I typically design web wallet payments so that the main merchant site starts a payment operation in the system, then the request returns back to the browser which polls the server for updates. when the backend server has sent all relevant details to the wallet and received back the request confirmation, it updates the transaction status to “ready for redirect”. Client app, in the browser, upon getting that status, reads the information required for redirection and forwards the user to the wallet web site. Upon completion, wallet forwards the user back to the payment status page, where the browser polls the server again periodically for status updates. The wallet system will also typically send the approval to the merchant server, which then updates the transaction status to “complete”. the workflow is a bit different for wallets that do not send backend-to-backend updates but that difference is not really important for this story.

I’d organise the ticket example by reserving the ticket on your end, then sending off the payment request, and if that request succeeds then confirming the ticket reservation. If the payment fails, then releasing the ticket. Reserving a ticket would be a short atomic DB operation, so the concurrency of that would be controlled by the database (even if two reservation requests come at the same time, the DB will refuse one transaction or block it until the first one finishes). The speed of payment processing then does not matter.

Your thoughts in this article is a very good aspect to be considered for architects designing their products. And it has been covered very well under 3 good ideas.

I have one question:

1) With regard to asynchronous processing, you have given the example of credit- card authentication. But in the case of payment using internet banking, how can we make it asynchronous? May be this is not an appropriate question, but can that process be made asynchronous?

Payment thru’ internet banking involves punching into the bank’s site from the main shopping website, logging in with authentication, and processing of your card details and authentication of transaction password details.

Related to the same topic, I can think of another example like flight booking. Say for example, there is just 1 ticket left for you to book, from Moscow to Chicago. You place an order, an order id is created (as you have given in your example), and the authentication process is delegated. In between the process of creating an order id, and authentication, there could be another thread (user request) which creates another order id for the same ticket. If the second thread is fast enough, the first user cannot get the ticket which is not a desirable situation. Also, there may be a case where the first user’s money may have been debited, but ticket not issued, because the second user used a credit card (instead of internet banking) and his card processing ended sooner.

Isn’t this whole transaction of booking atomic? Placing an order for a ticket and authentication of the process?

Or, would we allow only one order id to be created and maintained in the database at a time to avoid this situation?

Please let me know your thoughts.

My current server environment is as follows (3 servers):
- webserver running IIS and hosting the app components that invoke the long running TX
- DB server running SQL Server
- Another server (server X) which runs a third party software package that communicates to external systems. This is what processes the long running TXs. They are processed synchronously.
- App component on webserver sends request to server X which processes it and returns whenever it’s done. App component then writes results to DB.

My goal is to keep the webserver as unburdened as possible and keep page response time relatively constant. To do that it appears that I’ll have to implement browser “are you done” polling. The real work would be, and is, done on server X which calls external system but the app thread on the webserver would still be waiting synchronously for the response from server X.

I could probably wrap the long running TX on server X and invoke it asynchronously from the app on the web server but as the real work is being done on server X and not the webserver I’m not sure if that would buy me much.

first of all, I would not execute the external request from the web server at all. Ideally, I’d delegate that to another server. Depending on your server architecture (and whether you use a web server or an app server to process web requests), you might be able to launch background threads in the web server itself, but again the goal is to relieve the web servers from as much stress as we can – and delegate long running work to background operational servers.

Regarding the other part, it really depends on the external service. Some card processor run synchronously, some card processors send you a notification when the transaction has been authorised. (so typically you don’t poll, they call you when the job is done).

Here’s the situation:
1. browser sends request to webserver
2. app on webserver submits request to external system that may possibly take a while (let’s say possibly 20-30 minutes). Have no control over the external system but have to account for it.
3. browser polls for a limited time (30 seconds) and after that displays a message telling user to check order status page and maybe redirects to some other page.

I guess my question has to do with the server thread that made the request of the long running external service and that has now been ‘forgotten about’ by the browser.

1. Is the request from the server to external system typically synchronous or asynchronous?
-If sync, the server thread sits and waits.
-If async, then the server must be able to poll the external process for progress or the external process must provide some type of call back.
2. What is standard practice, if there is such a thing as standard? What do you see as the more common architecture?