Hotstar X Journey Part 1 — Why Rewrite?
This is the first article in a series of blogs that will describe how we evolved the Hotstar platform to its next generation version.
The Disney+Hotstar platform is the largest OTT provider in India. The platform also powers the Disney+ app across countries in MENA, SEA and the SAARC region.
The original Hotstar platform (code-name Rocky) was evangelised and built 3 years ago. Rocky was a true rockstar and it proved its mettle through multiple large scale events and helped us scale for audacious goals. However, the ageing of the platform had now started to show through the cracks. Rocky’s architecture was inline with what a start-up would rightfully do: Client side orchestration of business logic, domain apis directly exposed over CDN (as an api gateway) that the client would directly invoke and a set of domain services that handle various concerns like cataloging, payments, ads, recommendations, etc.
As the Hotstar platform evolved for newer business and customer use-cases, we started to observe some key barriers.
- Loss of Customer Delight Pace : Every new feature release or even a simple A/B experiment to turn on/off some features required client app releases. The pace at which we want to delight our customers requires us to be lot more agile and this was something that could not be achieved with a client heavy architecture.
- Sub-Optimal Client-Server Interactions : The client side orchestration meant that we were making multiple round-trips to our backends before the UX could start to paint itself. We knew that we could unlock lot faster and slick experiences if we optimized for network chatter by stitching data on the backend.
- Clients Management Insanity: With more than 20+ unique apps and platforms to support, client side architecture meant that every feature had to be built and released those many times. Often times this resulted in us over indexing over our largest customer footprint (Android), while other platforms struggled to catch-up.
- Inconsistent Cross Platform Parity: Even with this duplication, there was no surety that the features were built with high fidelity and same specs. Heck, even within a single platform there was little to no governance. As such two similar functional features on the app may be unintentionally developed as independent and diverging modules.
- Missing Design System: Last but not the least, we wanted to unleash a fresh, engaging and cohesive design and UX. This meant that every component had to speak the same design philosophy and had to be thought afresh.
The stage was set for a major shake up in the overall Hotstar architecture and we started to deliberate on various options ranging from piece-meal lift and shift (incremental migration) to platform specific evolutions. But at Hotstar, we love to take on big bold bets and thats exactly what we did!
We figured that while we may be able to control the amount of unknowns with an incremental migration, we may never be able to pay off all the tech debt that had accumulated in the Rocky architecture with this approach. For instance, we wanted to align on common specs for our client libraries that handled concerns of storage, network, analytics, etc. An incremental migration would have held us back from disrupting those layers for many more years. Likewise, on the server side we may have had to take on lot more operational complexity of managing two sets of stacks.
We decided that we need a full rewrite of our stack and that meant re-looking at our entire frontend and backend architecture. And that is where the Hotstar X journey begins.
In the next set of articles, we will deep dive into the various technical and product choices that we made and how we pulled together a mammoth task of launching the new platform in 14 countries within a single day. Stay tuned!
We’re hiring across roles and functions! Come work with us and partake in the audacity! Check out https://careers.hotstar.com.
