Integrating STACS with Project Ubin V - A Client-First Approach to Technical Design

Event-Driven Architecture with Real-time UI

By: Jin Ser, Jayson Cheng, Aaron Soh

A Short Word - Introduction

We at STACS set out to integrate our clearing and settlement blockchain, the STACS protocol, with the Ubin payments network to enable atomic, instant Delivery vs Payment (DVP) of digital securities on STACS and payments on Ubin.

Our use case with Project Ubin V (see press release by MAS) was for investment banks to issue bonds and other asset classes such as structured products, funds and equities on behalf of a company on the STACS blockchain network as a seller and be able to accept payment of funds from the Ubin Payment Network. Buyers in our use case would be other banks looking to purchase bonds on behalf of their clients using
funds in the Ubin Payment Network.

During this 2-month process, we worked closely with the Accenture
team and the Ubin APIs to design and develop a scalable, production-ready
architecture that would deliver on both business requirements as well as
customer experience.

Customer experience is important because reducing manual touchpoints
required of business users will enable us to achieve our goals of increasing
operational efficiency throughout the entire lifecycle of managing a bond and other asset classes on the STACS blockchain. As such, the customer journey was designed with maximal automation in mind while ensuring that the business user retains full control over critical processes. 1 of the key design feature was to have the UI layer be updated asynchronously in real-time without relying on pre-set polling jobs at the UI layer to ensure that the business user can proceed to complete their operational processes with minimal wait times.

We present our architecture design and the technical and user
considerations that went into said design to help guide the thought processes of future integrations with the Ubin payments network.

Figure 1 - Event-Driven Real-time UI Architecture

Architecture Components:

The integration was built with the customer journey in mind with
maximum automation and the key components that make up this architecture is as follows:

• Stateless UI built with ReactJS

• Cross-Chain Application Backend
  
• Lightweight Polling worker
  
• NoSQL Database
  
• Messaging Queue Service

Stateless UI built with ReactJS

Stateless was an important design feature to ensure scalability and
decoupling from the application backend and this meant that we needed a tool that was lightweight.

Having a lightweight UI would also enabled our UI team to focus on
creating intuitive designs to deliver an optimal customer experience for users.
Additionally, our intuitive designs include the entire business process flows
so that we can further minimize user onboarding with an easy to use, yet
feature-rich UI.

This led to us choosing ReactJS as a lightweight tool that enabled
us to focus on creating intuitive business processes.

Cross-Chain Application Backend

The Application Backend dealt with the heavy lifting and intensive
data processing coming from both blockchain networks (STACS and Ubin).

With efficiency in mind, we decided to expose Asynchronous APIs from
the app backend to the UI layer to allow for non-blocking responses to be
delivered to the UI and optimize the web page load times.

This enabled us to run the processing logic in the background which
would be pushed to the message queue service once ready for real-time
consumption by the UI layer.

Encryption and sending of requests to the Ubin network are also
handled from the app backend.

Lightweight Polling worker

To scale the entire architecture to handle heavier workloads, an
independent polling agent or worker would be necessary to handle all end-client blockchain requests.

The polling worker must handle 2 on-going tasks: persisting each
incoming Ubin response and decrypting each response to publish to the Message Queue Service.

It is a tough balancing act between ensuring the worker is
lightweight while having sufficient resources to handle the above 2 tasks.

NoSQL Database

To enable traceability and reporting for each user, all returned
Ubin responses have to be stored safely and securely especially since the Ubin API only returned each response exactly only once. This meant that if
investigations had to be carried out to trace transactions, it would not be
possible to do so on our end.

We chose a key-value and document NoSQL database for storage since
the JSON responses from Ubin could be stored as-is and requires little to no processing for storage. Furthermore, we could maintain the same privacy for end-client users since the returned responses from Ubin are encrypted.

Decrypted messages are not stored and instead sent directly to the
Message Queue Service for consumption by the UI layer.

Messaging Queue Service

A messaging queue service (pub/sub mechanism) is essential to enable
real-time UI and an event-driven architecture.

In this case since requests to the Ubin Network and STACS are
asynchronous, the UI layer cannot afford to wait for returned responses which will impact the customer experience.

Event-driven updates to the UI will have to be conducted as and when
responses are received from Ubin and the app backend.

Flow of Transactions

Figure 2 - Transaction Business Process

From UI to Ubin and Back again

When the user triggers an action on the UI, API requests are fired
to the cross-chain application backend to be routed to either the UBIN or STACS networks. The flow of events that occur is described in detail below:

1. When a user triggers an Ubin request such as checking their wallet balance or subscribing to a digital security on STACS, the UI fires an asynchronous API call to the app backend.
   
2. The app backend processes and validates the request before sending an encrypted Ubin API request message.
   
3. The app backend then sends back a non-blocking API response back to the UI to enable fast page loads on the UI.
   
4. When the Ubin network has completed processing the request, it sends back a response which is picked up by the polling worker on a periodic basis.
   
5. The polling worker proceeds to persist the Ubin response message to the NoSQL database
   
6. The polling worker also decrypts the message and publishes to the message queue service. This is consumed by the app backend for further processing.
   
7. The app backend completes the request processing and sends out a separate message for the UI via the Message Queue Service.
   
   The new message is then consumed by the UI layer and the web page
   loads the new information asynchronously for the end-user.

Future Enhancements

While the current microservices architecture allows us to scale
individual components to match load demands, there are definitely improvements that we at STACS are constantly on the lookout for.

Critical features such as checking past messages from the App
Backend in the NoSQL database need to be further enhanced to provide
investigative tools to trace past transactions.

Another essential feature is Traceability of transactions going from
Ubin to STACS. This will require further exploration of the “extra info”
attribute of the Ubin API specifications.

The team at STACS continues to be excited to work closely with the
Ubin network and we will be building out more features that would enable
business needs to be met and provide a high quality user experience for
business users to perform their tasks intuitively and efficiently.

A big shout out to the Project Ubin team for providing assistance with
the Ubin API integration!

Stackonomics: More of our insights on LinkedIn towards a blockchain economy. Hackernoon Contributor's Note: Isabelle believes in a tech-focused future and has the rights to publish this, working with the technical team Jin, Jayson and Aaron in STACS.