Rahul Chari shares how Core Technology Platforms work at PhonePe

How do Core Technology Platforms work for PhonePe?

Rahul Shares:

The approach that PhonePe has taken is not typically what most startups did, at least 5 years back. There is a value in that, and it is not easy because it demands much more time and patience from the company as a whole. But we, as a team, myself, and the engineers who have joined very early, own and run the technology platform at PhonePe. We are clear about having a blueprint that separates our core platform from the business verticals or the technology layers built on top of it to deliver for the business. To name a few, there is a core payment platform; there is an accounting platform, there is a growth platform, and there is a risk and fraud retention platform. These are the core platform; most of our business verticals are built on top of this.  The approach that we have taken is a clear set of principles that we operate with on each of these. For example, we follow a clear shared-nothing architecture, where we don't allow common databases to exist across the company, where you are overloading it with all the data; a design part that is followed mainly because it tends to be the easier path to take and its tends to have a certain level of short-term optimization where all the data is available in a consolidated manner for any of the microservices to fetch and deliver.  Similarly, we have a principle around non-caching; we don't create mega caches; it's always a gain to have a mega cache just behind your edge layer so that you can deliver most of the data that is pseudo-static quickly to your app or your website. It is a design pattern that has short-term gains but creates long-term problems, whether it's about the staleness of the data or whether it's about having integrity failure when it comes to the data itself because of staleness.   Today, each of these is an ecosystem by itself; we scale them independently because you realise that your workloads are different as we grow. A workload on your growth cluster could be very different from your workload on the payment cluster than on your account cluster. We can manage a clear allocation strategy when it comes to hardware; we can focus on the performance and scalability of these systems individually because they are not intertwined, they are core ecosystems, and we can improve them at their own pace. We are able to think about externalising some of these services and create almost all revenue tracks out of technology. Now, if you have to follow a design pattern that was significantly intertwined or was almost monolithic irrespective of whether you are a microservice or architecture or not, you could be monolithic as the technology stack in a company, and then you are never able to imagine possibly creating a business line out of the technology.  It is not about AWS, but each of these services by themselves has a vast IP that we could externalise. We are now imagining our world in that direction as a technology group, not as a company; just as a technology group, we can create revenue lines. I think it has already paid us massive dividends. The other thing that has helped us go down this path is a very clear demarcation in the company about demands on the core platforms vs demands on the business verticals. Everybody takes a long view of the demands on the core platforms; even if they are compliant about it within the company that it takes a long time to develop new capabilities in payments or risk and fraud or growth. They also realise that they can extract significantly higher value when they get built. So even if it takes six months to build a new core capability in payments, they know for a fact that the next year or a year and a half, they have the opportunity to milk that capability. So they have developed patience in terms of not being top-down with dates. Unless it’s a compliance or a regulatory requirement, we try not to impose top-down dates on our core platforms. On the business vertical itself, you make a growth hike; that is what it does because this model forces product managers, businesses and engineers to try and create more value out of the features that have been developed versus gravitating towards the next shiny object. Culturally, we have designed ourselves to operate in this model, so it is a combination of the tech principles as well as the model of operation that delivers the results.  

Authored by Pratheek. V

To find out more, watch the entire podcast here: https://youtu.be/Wbg_MQgj4Do