Case Study

Let’s take the example of the Instant Payment system where the sender is sending money from one bank and the receiver is from another bank receiving money. There is National exchange acting as intermediary coordinating payment between these two entities. Overall processing from sender to receiver in real world is bit elaborate, thus this article considers the only receiver and receiving bank journey as a piece out of the above scenario for rest of the discussion.

• Sender Bank
• Exchange
• Receiver Bank

Let’s assume receiver side before actual payment can be credited to the account of receiver, Sequence follows like

• Incoming credit request coming from exchange
• Check Receiver account Exist.
• Check Receiver Account is Active
• Check incoming transaction is duplicate.
• Sender fraud validation
• Amount day limit check
• Credit of amount to Account in some legacy Platform
• Making an Entry of the received funds in the ledger
• Publishing the transaction to data warehouse

Once all of the steps finish, the transaction is considered complete and response is returned to exchange.

Rest Architecture Type 1

Let’s convert above example into its rest equivalent API(s)

Now in the legacy world, this all will be bundled in monolith and delivered from the same package (WAR/JAR). At the same time all these APIs and step 8 and 9 will be called sequentially and final result is returned back to the caller.

Major drawback of this approach?

Our curated system in not able to meet the SLA defined by the Exchange is giving say 1500 milliseconds to return the response. DBA and Leads team did fine tuning of their GC and DB queries introduced caching for frequently used data but could not reduce the response time below 15 secs. There is a 10x gap in SLA and current response time. This problem gave rise to new way of architecting our Rest APIs where we can divide the entire transaction journey in two phases with separate bounded context to meet the SLA yet doing all.

Introducing Rest Architecture Type 2

Given the challenge of reducing SLA by 10x, we have to re-think and try recalibrating design considerations. The above approach, which was considered state of the art decade back is falling flat with new realities coming to the fore.

Let’s divide the above set of services in two groups.

• Services in critical path
• Services Not in critical path

Group 1

Services that should be successfully completed before confirming to exchange that receiver bank is good to commit the transaction that we call as phase 1 service called authorize or services that are in critical path. These services are called Group 1 service. Receiver bank needs to introduce a new service say Authorize to the exchange this will ensure that receiving bank is all good to commit the requested transaction and in turn can be acknowledged by the exchange to sender bank.

Second optimization is about identifying the services that can run in parallel. From the above set checking the account it exists and transaction is duplicate or not can be done is parallel so is checking the authenticity of the sender. Now when we run all these 3 calls in parallel maximum time taken for all three operations together will be governed by slowest transaction. With these modifications in architectural styles, it will substantially reduce the response time of the Authorize service which was 10x of permissible SLA earlier., Apart from this all-above optimization related to GC, DB, Caching still hold true.

Group 2

These services are book keeping services not part of critical path, thus reducing the overall processing time needed for the transaction. This put additional responsibility on the system to recover from the failure of itself. As external entity will proceed and not wait from second acknowledge call since this phase will give the final transaction details to the API and help matching phase 1 call with phase 2 calls for some timeout scenarios where receiver bank sends the response of authorize but it never reached to the exchange.

Rest Architecture Type 2 choices and its eventual impact

Type 2 architecture is good at meeting SLA at the same time ensuring the consistent state of the system. But like any other architecture it has its own shortcomings.

Added Complexity

Increase in number of Call.

Self-Recovery as an attribute in case of failure, it is the responsibility of the receiver bank to bring back the system to the state where actual amount is reflected in the receiver account.

Possible delay in receiver receiving amount if there are some failures in internal system and reconciliation is taking time

Yet Type 2 approach is a better choice than type 1 as it reduces the risk of failure, meets SLA and avoid single source of failure by dividing the processing in two phases instead of one.

Security Layer impact on Rest API architecture and SLA

Security is another factor that influences SLA indirectly. Extraneous security can have an adverse impact on the SLA. Too much gatekeeping will certainly impact the system performance. One possible approach that can be adopted that can get best of both the worlds is to keep the security layer at the API gateway level and internal APIs can communicate freely with whitelisting of the nodes that can connect to a given service. But above suggested approach is only viable provided your security architecture gives heads up on the same.

Conclusion

As the ecosystem is evolving what once upon a time was state of art becomes cumbersome. Two approaches discussed share the evolution journey that current systems are moving towards. It is important to keep on recalibrating the architecture and design decisions as ecosystems evolve and the requirements change.