This presentation was original given at OSCON in July, 2011. It was my first OSCON presenting on behalf of Netflix.
The Netflix API was originally launched 3 years ago to expose Netflix metadata and services to developers and build applications. It now handles over 1 billion requests per day from over 20,000 developers and 13,000 applications. However, Netflix has undergone many business changes and the API needs to be redesigned to focus on its core streaming business and support international growth. The new design will build a scalable data distribution pipeline to deliver customized, optimized metadata and services to each streaming client and platform. It will use wrappers and response handlers to customize the response for each device and isolate problems. This will allow faster development and reduce the need for versioning across many client types and interfaces.
I was invited to Bristol, CT in May, 2011 to give this presentation to ESPN’s Digital Media team, focusing on the trajectory of the Netflix API. I also discussed Netflix’s device implementation strategy and how it enables rapid development and robust A/B testing.
Daniel Jacobson is the director of API engineering at Netflix. Prior to Netflix, Daniel was at NPR where he created the NPR API as well as the content management system that drives NPR.org, mobile platforms and all other digital presentations for NPR content. Daniel is also on the board of directors for OpenID.
This is Daniel Jacobson, Director of Engineering for the API here at Netflix. The Netflix API launched in 2008 with a focus on the public developer community. The expectation was that this community would build amazing and inspiring applications that would take Netflix to a new level in serving our members. While some fantastic things were built by this community, including sites like Instant Watcher, the transformational moment for the API was when we started to use it to deliver the streaming functionality to Netflix ready devices. In the last year, we have escalated this approach to deliver Netflix metadata through the API to hundreds of devices. All of this has culminated in tremendous growth of the API, as represented by the following chart:
The tremendous growth of the API over the last year is due to a combination of the increased number of users, more activity by our users, Netflix’s steady adoption of new devices over time, as well as chattier interfaces to the API.
Growing the API by about 37× in 13 months indicates a few things to us. First, it demonstrates the tremendous success of the API and the fact that it has become a critical system within Netflix. Moreover, it suggests that, because it is so critical, we have to get it right. When reviewing the founding assumptions of the API from 2008, it is now clear to us that the API needs to be redesigned to carry us into the future.
Establishing New Goals
In the two-and-a-half years that the API has been live, some major, fundamental changes have taken place, both with the API and with Netflix. I already mentioned the change in focus from an exclusively public API to one that also drives our device experiences. Additionally, at the time of the launch, Netflix was primarily focused on delivering DVDs. Today, while DVDs are still part of our identity, the growth of our business is streaming. Moreover, we are no longer US-only. In October, we launched in Canada with a pure streaming plan and we are exploring other international markets as well. Because of these fundamental changes, as well as others that have cropped up along the way, the goals of the API have changed. And because the goals have changed, the way the API needs to operate has as well.
Decreasing Total Requests
An example of where the current design is inefficient is in the way the API resources are modeled. Today, there are about 20 resources in the API. Some of these resources are very similar to each other, although they each have their own interfaces and responses. Because of the number of resources and the fact that we are adhering very closely to the REST conventions, our devices need to make a series of calls to the APIs to get all the content needed to render the user interface. The result is that there is a high degree of chattiness between the devices and the APIs. In fact, one of our device implementations accounts for about 50% of the total API calls. That same device, however, is responsible for significantly less streaming traffic. Why is this device so chatty? Can we design our API to reduce the number of calls needed to create the same experience? In essence, assuming everything remains static, could the 20+ billion requests that we handled in January 2011 have been 15 billion? Or 10 billion?
Decreasing Payload
If we reduce the number of requests to the API to achieve the same user experience, it implies that the payload of each request will need to be larger. While it is possible that this extra payload won’t noticeably impair performance, we still would like to reduce the total number of bits delivered. To do so, we will also be looking at ways to handle partial response through the API. Our goal in this approach will be to conceptualize the API as a database. A database can handle incredible variability in requests through SQL. We want the API to be able to answer questions with the same degree of variability that SQL can for a database. Other implementations, like YQL and OData, offer similar flexibility and we will research them as well. Chattiness and payload size (as well as their impact on the request/response model) are just two examples of the things we are researching in our upcoming API redesign. In the coming weeks, as we get deeper into this work, we will continue to post our thinking to this blog.
If these challenges seem exciting to you, we are hiring! Check out the jobs on the API team at our jobs site.
Last night, I had the pleasure of joining my old colleagues from NPR at the Online Journalism Association’s award ceremony in DC. First of all, it was great to see the gang again after three weeks as a non-NPR employee. It was also great to see NPR nominated for a wide range of awards (eight in total). The highlights for me, however, were that the NPR API won its first award (explicitly) and the fact that Kinsey Wilson won the Rich Jaroslovsky award (congratulations, Kinsey!).
The NPR API won the Gannett Foundation Award for Technical Innovation in the Service of Digital Journalism, which is a huge honor! I couldn’t be more proud of the NPR team, and more specifically the NPR Digital Media Tech Team, in claiming this. The work that the team did is amazing and it is great to see that work getting recognized in such a prestigious fashion. I am also very thankful that Kinsey invited me to accept the award on behalf of NPR. Representing such a tremendous team in this forum is a huge honor for me. While accepting the award, I explicitly thanked Zach Brand and Harold Neal as my “partners in crime” in getting the API live. While I stand by that statement, I do wish I explicitly thanked the rest of the Tech Team who has played a very important role in the evolution of the API since its launch in 2008.
Congratulations to Demian Perry, Jeremy Pennycook, Jennifer Oh and the other contributors to NPR Mobile as well, for winning the award for Outstanding Use of Emerging Technologies.
I look forward to seeing more great achievements from NPR going forward. I expect that there will be many…
Comments Off on Presentation : Redesigning the Netflix API – OSCON 2011 
Themocracy