The article gives a high-level overview of the architecture of the RIVIGO Goal App, an android application to empower sales teams with data-driven decision making. It also covers in more detail two of the application’s features, namely, daily organizer and travel reimbursement.
The RIVIGO Goal App is an android application which empowers our sales team with unparalleled and real-time data and intelligence. It works on the fly even with flaky data connectivity to support our sales team as they continue to be on the field.
The goal system has four major sub-components deployed as multiple microservices with a user facing android app.
Our backend application is written in java using spring boot framework. There are primarily two application servers – API server and scheduler server along with storage and cache in RDS (MySQL), MongoDB, Redis and ElasticSearch. The primary purpose of the goal backend is to serve requests from android apps and get processed data by subscribing to or pulling information from multiple sources.
Data source backend
This backend server is a central repository of all processed data which is used by all internal systems.
Data science engine
This is the most powerful sub-system which reads events from several systems, applies complex algorithms and publishes all data intelligence APIs.
Serverless event handler
To build the goal app as a PaaS (platform as a service) and for any high throughput activities from millions of devices (like capturing geo-location), we need an infinitely scalable architecture. This service is responsible for consuming event data packets from authorized applications and forwarding those to AWS SNS topics, which will then be consumed by respective listeners/applications. The main objective was to make this service fast and capable of handling high throughput. Hence, we decided to use AWS lambda serverless architecture. To make the execution speed and development time faster, we chose Golang as our development language.
Some of the benefits of using serverless are mentioned below.
While there are several complex features, for the scope of this article, let’s dive deep into two of them.
Meeting scheduler is one of the key components of the goal app. It enables sales executives to optimize productive meetings in a given day. The objective of this engine is to maximize the incremental business potential per meeting while minimizing distance travelled.
The above diagram explains the workflow of the engine, which generates a seven-day rolling beat plan for every sales executive informing him of his meeting schedule.
The engine has published APIs which are used by the goal app backend system to fetch the beat plan and daily meeting schedules for all the sales executives on demand. The engine uses the user profile data and the self-learning model predicts the user business potential volume based on leading indicators such as network centrality, app browsing history etc.
Given predicted user business potential, the system calculates incremental business potential based on the trend of historical transactions. Spatial-based clustering algorithm forms location clusters using the potential and location data. Using these clusters, the optimizer generates the next seven days rolling plan such that overall business per day is maximized and distance travelled minimized.
In this way, the goal app system not only helps sales executives decide whom to meet but also helps them run their meetings efficiently by providing them end-to-end visibility of all the data points in a single screen.
Travel/fuel reimbursements is a non-value adding activity in our sales executives’ life. Hence, we have automated this reimbursement calculation. Our app starts capturing the user’s location data when he starts his day by clocking in/marking his attendance on app. The app then pushes this location data to the backend servers ensuring minimal battery usage by several optimizations like batching, detecting speed of travel, staggering, etc.
User location packets are sent to the event handler by our android application which is then forwarded to an SNS topic. The scheduler server consumes that location data from SQS (AWS queue) and dumps to a mongoDB. A cron runs daily which reads the time series location data from mongoDB and calculates the distance travelled by each sales executive. This distance travelled combined with the standardized rates as per policies is used to calculate the reimbursement amount. This amount is then reimbursed in his fuel wallet which can be used to buy fuel at most of the leading petrol pumps.
While we have started with building this product primarily for our internal teams, our goal is to develop this as a ‘Platform as a Service’ product so as to be able to offer this service to the larger ecosystem.