Leveraging Asynchronous app and Pub/Sub for Shared Pocket
Shared pocket is an innovative banking feature. Never before a bank account can be easily shared with your family and friends in real-time! For those of you who want to know more can read this article about the Shared Pocket ideation and creation process.
So, how do we make the feature possible? What are the challenges we faced during development?
Before we dive deeper into the Shared Pocket technical challenges, the solution and the architecture decision. Let us take a look at the Jago app which houses it.
Fully Asynchronous Flutter app
The key selling point which Jago is pursuing is “Speed and Performance”. Given this premise, and that the majority of the customers are using low-end Android mobile devices, we had to consider the most suitable architecture and framework for the given objective. Flutter was chosen over React Native for this reason.
Jago app is a fully asynchronous Flutter app. The main benefit one can gain from using asynchronous programming is improved application performance and responsiveness. One particularly well-suited application for the asynchronous pattern is providing a responsive UI in a client application while running a computationally or resource expensive operation in the backend.
Consider this, a user intends to do 4 tasks:
- Task 1: transfer money to external banks/e-wallets which typically takes a longer time
- Task 2: transfer money to an internal bank account
- Task 3: paying the electric bill
- Task 4: transfer money to another account.
In a traditional app, you will need to wait for each task to complete before you can do the next one because the UI will freeze. And only when the server completes the task then you can proceed.
But that’s not the case on Jago app. You can execute all your tasks at once, no need to wait until one is completed first. When a task is running, you can still use your app and look around. The Asynchronous figure above may be exaggerated time-wise, but it describes the vision to have a highly performant app where the customer doesn’t need to wait.
Different to the typical Synchronous app where REST calls are made to the backend and then wait for the response, Jago event-driven backend uses Messaging broker platform to enable data to be streamed asynchronously from backend to mobile devices in milliseconds.
Message routing nightmare
With this architecture, Shared Pocket becomes a technical challenge. How can we deliver to multiple devices of participants of the Shared pocket?
For example, you have 7 participants in a shared pocket. When Participant #1 deposits some money into the shared pocket; then upon successful completion of the deposit process, the backend will need to know the mobile devices from Participant #2 to Participant #7 and then route the message correctly. The same deposit event will have to be repeatedly delivered to the message broker more than 7 times and then sent to more than 7 different devices. Why? Because each participant may have more than 1 device!
Along comes Publish-Subscribe pattern to the rescue!
Shared Pocket as Publish-Subscribe service
Pub/Sub enables you to create systems of event producers and consumers, called publishers and subscribers. Publishers communicate with subscribers asynchronously by broadcasting events, rather than by synchronous remote procedure calls (RPCs). (Here is a Pub/Sub video overview and how it can help in this case.)
Shared Pocket modules can now be programmed asynchronously. Message delivery does not block the publisher. The publisher gets back to its task after publishing the message. Similarly, the subscriber gets interrupted only when there is a message on a subscribed topic.
With this pattern, the idea is to have Shared Pocket ID as the topic; then participants of the Shared Pocket act as subscribers; while any participants who do something to the Shared Pocket are acting as publishers. The event of the Shared Pocket itself becomes the message.
When a user deposits/withdraws money, that user’s Jago app instance publishes the message on that Shared Pocket’s ID topic. Subscribers of the Shared Pocket ID topic receive the message.
The message broker takes the responsibility of reliably delivering the message, thus freeing the developer from writing complex code to handle the routing. Using the same example of a Shared Pocket with 7 participants, instead of delivering more than 7 times, now it is only sending once to the message broker, then the broker will broadcast to all the participant devices.
This way, our codebase becomes simpler and reader-friendly. Furthermore, it simplifies the future expansion for Shared Pocket features.
Conclusion
From the beginning, our approach began with Jago Vision and Strategic Goals: creating highly performant life-centric financial solutions, such as the Shared Pocket. It becomes the driving factor behind how we decide on the application architecture. We avoid settling up a structure first then trying to build the application that fits within that structure, as it might deviate from the business vision or goal.
Along the way, there are other important things we took into consideration, such as rapid development of new services and updates roll-out as soon as a vulnerability is discovered. This flexibility and swiftness are our key competitive differentiators, and it’s reflected in our work as well.
Do you like crafting digital solutions using unorthodox methods? Let’s chat more on LinkedIn or better, join our team! We won’t byte 😉
