Patterns for integrating with a slow external service

Question

Was hoping someone could provide some patterns/techniques/ideas to increase performance for the following scenario.

Am integrating with an external ordering system via SOAP. The external system can be slow and unfortunately nothing can be changed at that end.

All products are retrieved from this external source and an order is only placed with the external system when they've paid so cart functionality will be implemented locally.

When a item is added to the cart, it will check the external source if there's enough stock and then add the item to the cart locally, and the user will stay on the same page (eg. wont' redirect to a cart summary screen). It will also check the rest of the items in their cart to ensure there is enough stock, so depending on how many items they have there could be a lot of calls to the external source.

I guess, could only check the stock levels for other items in their cart when they get to the checkout summary screen and subsequent checkout screens but i feel that isn't the best user experience.

For reference, local site will be using ASP.NET MVC3

Any suggestions?

Thanks

Answer 1

If you're going to be making a lot of calls to check the stock levels every time an item is added, that would imply the stock levels would change very quickly - it's worth looking at some statistics to see if this is actually necessary.

If it's not, you could create a simpler solution with a local store of the stock levels that gets updated by another process every 10 minutes (for example) - even better if you can get the external party to publish the stock list and you can just subscribe, but it doesn't sound like you've got much control over them.

You could then do a check against the external service to ensure stock is there before taking payment, process the payment and submit the order.

Answer 2

You'd need to perform the checking asynchronously - ie when an item is added to the cart, you fire off a request but do not wait for the response. Instead all responses go to a central queue and are then applied to the cart.

If an item is out of stock, then you will have to notify the user as they browse the site, possibly pop up a warning saying the item is unavailable. They will have an item in their cart with a red warning when they look. You could then cache the results and remove that item from the store (or mark it as temporarily unavailable) and intermittently re-check to see if the item has been restocked.

Also, when they reach the checkout area, you will have to pause while the queue empties and each item in their cart receives their check response.

It depends on your situation whether this will work well - if there are a lot of 'sold out' stock then this is probably not what you want to do, but in such a case, you will have no option but to wait for the response.