One simple, but quite under-used ‘pattern’, for want of a better word, is Asynchronous processing. This solves the Chained API Pitfall, along with a myriad of other challenges developers might encounter on a daily basis.
Let’s take a simple scenario. An operations system captures customer order information on the company website. Having captured this information, the web application submits the customer order to your API which, in turn, forwards it to the ERP system, sends a notification to the fulfillment team, updates a legacy inventory system and, finally, sends an email to the customer with their invoice attached.
In a traditional implementation, your API will receive the order, then attempt to process it end-to-end and, if all goes well, respond with a 200 OK.
The trouble is, you have now tied your website’s destiny, along with the entire customer experience, to the behaviour of four external systems and a network over which you have zero control.
Take a step back and think about it for a moment. The customer does not care about your ERP system, the fulfillment team’s notification or your email server; all they want to know is that their order was received.
Take a look at the flows below
In the above flow, we separate our processing from our API. This allows us to send a 200 OK response to the Web application and, by extension, the customers who use that website before anything has a chance to go wrong. This will improve the customer experience by orders of magnitude. The flow woks as follows:
- Our API receives the message with Customer Order Information
- We place the message on a Persisted VM Queue where it is safe and won’t get lost in the ether. Then we return an immediate 200 OK to the Web application. Now the customer, who placed the order, can get on with their life.
- A VM Listener picks up messages instantly as they arrive on the Processing Queue.
- Processing occurs as before
In other words, we still:
- Send the message on to the ERP system
- Send a notification to the fulfillment team
- Update the legacy inventory system and
- Send customer an email with attached invoice
More often than not, this process goes off without a hitch; the process takes no longer than it did before.
The major difference is what happens when things go wrong. Biggest benefit; the customer will never know that anything went wrong. In a worst case scenario, they will be a little surprised on those occasions when they actually notice that their email with invoice took a little longer to arrive than it usually does.
Of course, this means we need to cater for errors and write tight flows that guard these messages against loss at all costs. However, I would argue that this is our job as Whisperers. Once a system takes ownership of a message, it remains responsible for that message until it hands responsibility off to down-stream systems.
Of course, this approach won’t work in every scenario. For instance, if the API call requests data from an external system, and expects an instant response, that can’t be done asynchronously; your API has to return the data. If it is unable to, then it is forced to raise an error.
The above notwithstanding, you will find that there are many scenarios where the client really doesn’t require any information apart from a simple acknowledgement that the message was received successfully. In those scenarios, try the above implementation. It will save you and your support team a world of pain.