When building large web-applications we often encounter scenarios where several services have to be invoked successively, some in-house and some third-party external services. As we glide into the world of micro-services, the number of services to fulfil a single business transaction increases and the overall complexity increases. Given that some of these business transactions have guaranteed response time and some of them do not, it becomes imperative on the part of the designer to handle these transactions properly. The User Interface must be a stateless entity, whether it is designed for a laptop browser, smartphone browser or an App, meaning the UI must purely facilitate the user in sailing him through the complete business transaction and not maintain any state of the transaction. It should merely accept the data from the user, transfer the data to the backend systems, perform any simple calculations if necessary and receive data from the backend and provide a superior browsing and navigational experience to the user. All the dirty operations involving the data should be relegated to the backend. As they day, don’t wash your dirty linen in the public. The result of the overall business transaction must be handled retrospectively. Here’s where building a synchronous façade for an asynchronous transaction comes into fore, meaning if a transaction has no guarantee of response time, then UI should just provide a passive response to the user and maintain the state of the transaction in one of the many backend systems and allow the user to complete his UI transaction gracefully.

There are several ways to achieve this. A few of them are: 1) Using a seamless Event streaming solution (Eg: Kafka Streams), wherein the producer produces events and sends it to the Kafka stream and receives a passive response. The event persists in Kafka engine for processing at a later point in time or it can be consumed immediately and acted upon for real-time processing.

1) Use a Workflow and state-management engine (e.g.: Camunda) which receives events, persists them and updates the request state based on the event, orchestrate a set of micro-services based on the event. 2) Use a combination of both the tools, a streaming/queueing mechanism to persist, order/re-order the events which a state management engine can consume later to orchestrate a set of services depending on the event. I’ll focus on the point #2 above since this is the tool we mostly use for service orchestration and request state management.
Let’s assume the following scenario: At several points in our journey/request, we have to send correspondences to the customer/IFA regarding the policy status updates, documents required …etc. In certain scenarios, if the customer refuses to disclose the bank details on the call, then he must provide the bank account details as a physical copy, for e.g.: cancelled cheque leaflet, bank statement …etc. to validate the bank account. The front office agent, who is attending the call will mark the request as ‘Pending for additional documents’, at which point, an event must be triggered to send a correspondence to the customer to send out the additional documents. The correspondence service may or may not respond immediately. Hence the user must not be waiting in a blocked state, it must receive a passive response from the workflow, an acknowledgement upon receiving the event and the workflow must in turn invoke the correspondence service. The workflow will again not wait for the correspondence service to actually send the correspondence letters to the user and then receive an active response, the correspondence should merely respond with a token of acknowledgement indicating that the request has been received to send the document. The workflow will manage the state of the request, continuously poll the correspondence service to check the dispatch status of the correspondence, may be in an interval of once a day or twice a day and once it receives a positive response that the correspondence has been dispatched, it will update the request status retrospectively, to, let’s say, ‘Correspondence Sent’. Upon polling, if it is later determined that the correspondence dispatch has failed, then in this case, workflow can notify the back-office processor indicating that the dispatch has failed for the given request and an action needs to be taken manually. The back-office processor will later take an action on the request based on his discretion and knowledge. The back-office team is notified of the failure either by creating a task for the team or sending an e-mail to their group mail box.