HashedIn built a multi-tenant system for a leading technology company to digitize their free service coupon. The platform had multiple services like loyalty, service desk and after buy which could have been taken as a service by any brands. The platform managed the enabling of these services across individual brands with the data for each brand being segregated to make sure one brand never sees the data of another brand.
GladMinds Technologies Pvt Ltd is a Bangalore based company founded by industry professionals with a cumulative experience of over 120 man-years. GladMinds Connect Platform helps Brands and Customers to be engaged with each other enabling a superior experience and satisfaction. Their key mission is to simplify life.
GladMinds wanted to address the challenge that two-wheeler manufacturing companies faced, with paper-based service coupons that were getting increasingly difficult to manage. The idea was to minimize human errors at each level by moving on to digitized coupon.The implementation would also become a “go green” initiative which would help reduce paper consumption.
They also wanted to:
- Build multiple services that that can be taken quickly to the market
- Make the services based on subscription
- Cost of infrastructure
- Complexity in catering to multiple brands
- Making such a complex application and getting to market quickly
Since multi-brand support is required and for multiple services with options to make them pluggable the best option was to use the platform based architecture. The architecture should be scalable and perform well. To achieve all these and make it cost effective, we need an infrastructure with load balancers that can scale automatically and thereby pay only for the infra usage. The architecture is as shown below.
Each service is built as a separate module, having their own APIs and admin console. The basic idea was to allow a brand to sign up for multiple services, thus to manage all the brands and their services we built an admin console across the platform. Each brand had their own customized admin console for where they could manage their entities. The challenge was to make sure that the data for one brand is never visible/updated by another brand thus the data was to be maintained separately for which we created different databases. We made that sure by creating a middle layer where each request coming to the platform was the first process and then based on the brand name the layer will route the request to the respective database whenever the request tries to access the data.
The other interesting feature was integrating with different external services. We integrated with SAP to get the data of the vehicles dispatched or sold through the feed. At the end of the day, we even used to send reconciliation data back to SAP. To share data to and from SAP we created remote procedures. To receive data from SAP, SAP system used to post the data to our remote procedures in the form of XML. The procedure than used to process the data and feed them into our database. To send data to SAP we used to generate an XML and share the same with SAP team, we then used to insert the data into the XML format and post it to SAP. All the failures in any of these data feeds were recorded and reported.
For this architecture to be cost-effective, we need to build a scalable system that has auto-scaling capabilities. A scalable system is one where the performance improves after adding hardware, proportionally to the capacity added. We have a scalable system and to achieve this we have used “Auto Scaling”. It is a service provided by AWS that allows us to increase or decrease the number of instances of the server within our application’s architecture. With Auto Scaling, we create collections of EC2 instances, called Auto Scaling groups. We can create these groups from scratch or from existing instances that are already in production. We decided to use Elastic Bean-Stalk (EBS) provided by AWS that has the auto-scaling capability.
Elastic Beanstalk (EBS) helps us quickly deploy and manage applications in the AWS cloud without worrying about the infrastructure that runs those applications. EBS provides an easy to use interface that makes deploying or rolling back a version quick. EBS reduces management complexity without restricting choice or control. We just need to upload our application and EBS automatically handles the details of capacity provisioning, load balancing, scaling etc.
How Auto-scale works?
The diagram below is a representation of how Auto scale works
We designed a secured a secured infrastructure for GladMinds platform. We had set up a Virtual Private Cloud within which we had the auto-scaling servers and database under a private subnet and a load balancer in a private subnet. The diagram below shows the architecture we had, it also shows a proxy server setup for using Airtel services to send SMS as Airtel required static IP to push the messaged to our platform.
Access based control
Apart from a highly secured infrastructure, we had access based control at the platform level. Each brand could set their own groups with different level of access permissions to the platform, then they could add multiple users in those groups. We used Django’s groups and permission to achieve the granular level of permissions.
Agile development – Iterative Incremental model
We follow the iterative incremental model where we work on an MVP (Minimum Viable Product) that meets the basic requirement of the working model intended and can be shipped for review/demo with stakeholders. Every iteration adds new features to the existing working model. This helps in continuous review/feedback with the stakeholders and help in evolving the product with minimum changes.
- A cost effective infrastructure due to the auto scaling and therefore paying extra only for the duration the additional resources were used
- Secured database access through APIs
- Pluggable services
- Brand data separation
- Multi tenancy
- Easily extendable to a new brand