MyGP Case study: Selfcare App to Lifestyle Super App

Problem Statement

Grameenphone is in a journey of transforming the selfcare app to a lifestyle super app for the valued customers. The app need to engage the customers effectively through extensive personalization and offering contextual contents, offers and products. Gamification is another means of enhancing customer engagement. Integrations with the right partners and building an ecosystem around the app are essential for future success. The app will be the driver of 100% digitalization of Grameenphone customer journeys and the go to app for daily activities.

 

As an Architect of this app, along with the relevant CAPEX/OPEX owner  – How you would:

 

  1. Design the Architecture and transform the app – considering the scalability, stability, capabilities and integrations need from the app? Please design the architecture, detail out the probable transformation steps, challenges, mitigations towards the TOBE architecture
  2. Develop the application using best practices and technical stack. Detail out the technologies and development practices you would follow here and why.

Development team size and organization: How would you form and organize the future team and why? Please note: in GP we currently have both in-house and augmented resources.  You are open to go for any model like involving partner/managed service etc. as you think is required and appropriate considering the management and cost exposure of the team.

TOBE Architecture AT A GLANCE

Here’s the summarized presentation of the solution design.

You can view the presentation by following this link for a full page view.

**You can hover at the bottom to have navigation & control panel appear. 

ASSUMPTIONS

  • Frontend Application is developed with Native Android & Native iOS.
  • Backend Application is developed using PHP Laravel.
  • Platform is deployed is VM, at GP Datacenter, Not directly on top of bare metal. Approx. 1600v CPU. in total.
  • For Database, MySQL Enterprise (dedicated Cluster) is used.
  • For API caching, Redis Cluster is used.
  • Capable to cater approx ~4500 TPS
  • No WAF observed. Most likely Application Level Load Balancer is used using Nginx.
  • 15.5mln MAU
|| Forensic Analysis ||
  • During authentication layer, there’s a microservice observed, signin.gp-id.com which is hosted on AWS which is great but the server is located in AWS EU Ireland Region (eu-west-1) which is not quite logical since most of the customer base of GP is geographically located at Bangladesh. This API is called very frequently & this additional latency might result into customer dissatisfaction.
  • There’s a number of video content in the app – bioscope, bongo, skihho & others. For that, a heavy bongoplayerlib library is used which has some advance but costly features like DRM, YouBora Integration etc. Does this lifestyle app needs such heavy player? Also there’s integration with Cinematic SDK(com.live.tech.cinematic.sdk). Ideally, there can be an in-build lightweight player which will run all these VOD libraries.
  • For Analytics or Similar purpose, quite a few different platform is used, Google Analytics, Facebook Pixel, Adjust S2S SDK, Tapad Tapestry( https://tapestry.tapad.com whose server is located in GCP UK ), Youbora Analytics & telenor analytic( com.telenor.connect.AnalyticsAPI ). Rather that using separate platform, are there any scope for a single platform build on-top of a Open Source platform like Matamo & have an Omni-channel Analytics? 
  • For Gaming, gaak media &  bdgamers.club integration found.
  • For News, DailyStar Integration.
  • App has enabled in-app caching which is great. There’s some more candidates for in-app cache.
  • Lottie animation is there in the APK but didn’t see any extensive use of lottie animation.
  • Firebase In-app messaging & Crashlytics is used which is great.
  • ButterKnife library is used for view binding which is great.

FUNCTIONAL REQUIREMENTS

  • Need to ensure customer engagement through extensive personalization and offering contextual contents, offers and products.
  • Customer Engagement through Gamification.
  • End goal is to develop a Lifestyle super app through Integration with partners & develop the integration ecosystem 

NON-FUNCTIONAL REQUIREMENTS

  • Need to consider scalability, stability & capabilities
  • Need to have a Failover Capability in case of a disaster.
  • Ensure best-fitted technical stack & build the development team augmentation.

Key Challenges to be Addressed

From my experience dealing with such selfcare app, in my opinion, primary challenges are:

  • Unpredictable & Variable Traffic Load in a Spike pattern: Traffic pattern in such apps are highly variable. Generally at peak hour(usually 5:00pm – 11:00pm), TPS raise to a peak. Whereas throughout the day, platform remains quite stable & under utilized.
    • Rather obvious solution here is to develop an elastic infrastructure that can scale up & down accordingly with traffic load without any manual capacity augmentation. My suggestion will be to migrate the whole setup in a Kubernetes Cluster  
  • Endpoint Dependency: Primarily this app is a ecosystem that is connected with a number of Southbound nodes. If the application’s dependency injection is not maintained properly, It may end up with a highly monolith application & one southbound node failure affect the entire app. 
    • Platform should be designed as a decoupled microservice architecture in mind. Lumen can be used instead of Laravel(Both are compatible) to transform from a monolith architecture to Microservice architecture.

System Design for a LifeStyle Super App

GP Lifestyle Super App should be a central hub for all customer needs rather than only being a Telco Self-care app.

Here’s a 10,000 feet overview of how the TOBE platform should look like:

To perfectly design the platform, need to identify the services to be added, below are the proposed feature list MyGP LifeStyle Super App should have:

Application Architecture

Ideally GP should develop a Mini-App framework to build a ecosystem for other service providers to host their platform in MyGP ecosystem hub.

GraphQL can be used to offer flexibility to service providers.

 

Frontend Application Architecture

While assessing the 3rd party integration of MyGP android app, I found that most of these integrations Library integration. While that is valid but there’s a more advance option, Android Dynamic Features(App Bundle) which will make the app lighter & faster. 

Database Architecture

This platform will ideally be a Read-heavy platform. Hence we need to ensure a greater number of Read-Replica while deploying the database.

Apart from that, regarding selection of RDBMS engine, from a performance perspective, Oracle will be better but considering license cost & management aspect, Oracle seems to be a overkill for such Lifestyle app.

However, PostgreSQL can be a Great fit in this context. 

Summary

All in all, I want conclude by thanking you to give me an opportunity work on this very interesting case study. I thoroughly enjoyed the journey.

I believe that in System Design, there’s no absolute perfect design. All depends on specific use case & scenario. While I have suggested this system design for the component, I’m open for suggestion on any steps while we can design that part in a different angel. 🙂