Event-Driven Architecture with Real-time UI By: Jin Ser, Jayson Cheng, Aaron Soh A Short Word - Introduction We at 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. STACS Our use case with 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. Project Ubin V (see press release by MAS) 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: 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. The app backend processes and validates the request before sending an encrypted Ubin API request message. The app backend then sends back a non-blocking API response back to the UI to enable fast page loads on the UI. 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. The polling worker proceeds to persist the Ubin response message to the NoSQL database The polling worker also decrypts the message and publishes to the message queue service. This is consumed by the app backend for further processing. 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! Hackernoon Contributor's Note: believes in a tech-focused future and has the rights to publish this, working with the technical team Jin, Jayson and Aaron in . Stackonomics: More of our insights on LinkedIn towards a blockchain economy. Isabelle STACS

Flow

Trace

Read My Stories

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps