Redesigning the Netflix API - OSCON

Editor's Notes

• #5: This is my paraphrase of what the original intent of the Netflix API was.
• #6: A visual representation of the original charter
• #7: The result of the 1,000 flowers model is a wide range of apps and sites built by third-party developers. These are some examples of them.
• #8: Extending our community engagement was the Netflix Prize, which exposed a fixed dataset to registered teams who would work to improve the Netflix recommendations algorithm by 10%. The winning team would receive $1M. There were several thousand teams that participated in the prize, which lasted about three years.
• #9: Then streaming started taking off for Netflix, first on the desktop and then on devices.
• #10: As we broadened the device support, we leveraged the Netflix API to deliver the content. The 1,000 flowers were then sharing the API with internal and external development teams who produce Netflix-branded streaming apps.
• #11: Over time, streaming really took off and now streaming is supported on hundreds of Netflix-ready devices.
• #12: The explosion in streaming usage has resulted in tremendous growth in the Netflix API. In the last 12 months alone, the API traffic has gone up 12x, from about 2.5M requests per month to about 31M.
• #14: As streaming took off, the API continued to morph to support the needs of streaming on hundreds of devices.
• #15: Moreover, when the API launched, Netflix users were consuming substantially more DVDs. Over time, the focus of the company has shifted more towards streaming.
• #16: Meanwhile, major architectural challenges have been undertaken, such as moving the entire streaming operation from data centers to the AWS cloud.
• #17: Finally, when the API initially launched, we were a US-only service. Now we are in Canada and have announced expansion to 43 countries in Latin America for later this year.
• #18: There have been many incremental changes to the API, but none fundamental in the way that match the growth of the business.
• #19: So, the 1,000 flowers, who previously accounted for 100% of the total API traffic, now account for < .3% of the total API traffic.
• #20: Currently, the API is still based on the design that was targeted towards the public third-party developers with the streaming devices running off the same design.
• #21: What we would like to get to is redesigning the API to be targeted towards the key audience (the Netflix-branded streaming devices) and then trickle down the features to the third-party developers.
• #23: Metrics like 30+B requests per month sound great, don’t they? The reality is that this number is concerning…
• #24: In the web world, increasing request numbers mean increasing opportunity of ad impressions, which means increasing opportunity for generating revenue. And when you hit certain thresholds in impressions, CPMs start to rise, which means even more money. That is why some media companies have stories spanning multiple pages, etc.
• #25: And some companies, like The New York Times, create more opportunity for ad impressions by article pagination.
• #26: But for systems that yield output that looks like these documents, such as APIs, ad impressions are not part of the game. As a result, the increase in requests don’t translate into more revenue. In fact, they translate into more expenses. That is, to handle more requests requires more servers, more systems-admins, a potentially different application architecture, etc.
• #27: We are challenging ourselves to redesign the API to see if those same 30+ billion requests could have been 5 billion or perhaps even less. Through more targeted API designs based on what we have learned through our metrics, we will be able to reduce our API traffic as Netflix’ overall traffic grows. Reduction in traffic results in lower server counts (and costs), fewer demands on systems infrastructure engineers, etc. More importantly, if rendering a single page on a UI can be done in 2 transactions instead of 15, the end user will see tremendous benefits in overall performance of the app.
• #29: So, we are now on hundreds of devices. How do we modify our development approach to make it easier to add new devices? How do we improve the efficiency around device implementation to match the efficiencies that the API provide us?
• #33: So, we are now on hundreds of devices. How do we modify our development approach to make it easier to add new devices? How do we improve the efficiency around device implementation to match the efficiencies that the API provide us?
• #39: Netflix has an array of internal engineering teams who specialize in discreet problems, such as recommendations, movie metadata, reviews, ratings, etc. That content needs to be delivered to the hundreds of Netflix-branded streaming devices (many of which are developed by internal engineering teams within Netflix). The API is the central pipeline that delivers that material to the devices.Right now, the API is a generic pipeline that the individual devices all call, basically in the same ways.
• #40: We would like to get to a model where the API, in addition to offering the generic pipeline, also offers custom endpoints that the devices can call to replace the high-transaction needs currently found in rendering more complicated screens on the various devices. These custom endpoints will allow the API to do the heavy lifting in preparing the responses needed to render these complicated screens rather than requiring the client apps to handle it through many API calls.
• #41: The model may look something like this, where the solid vertical black line to the right is dividing the clients from the servers:Client app makes a call across HTTP to a request handler.The request handler determines if the request is a custom endpoint or a generic one.If generic, the request gets sent to the API engine.If customer, the request goes to a request wrapper that knows what this custom endpoint needs. In some cases, it will explode the single request into many so it can retrieve all of the necessary data for the request.The API engine, in all cases, will make the appropriate calls to the dependencies to get all of the information needed to compile a response.The dependencies’ output will get pushed to a serialized metadata object that passes the response metadata up the stack to prepare delivery.The API engine, once brokering all of the metadata, will pass the serialized object to a response wrapper that determines what formatting script is needed to prepare the response.If the request was to a generic endpoint, the response wrapper handler will pass the serialized object to the default response wrapper where the response will be formatted and delivered.If the requests was to a custom endpoint, the response wrapper handler will pass the serialized object to the appropriate custom wrapper where the serialized object will be pruned, formatted and delivered in the optimal way for that particular device and UI.
• #42: As we expand internationally, this degree of flexibility becomes even more important as the variability of devices, Uis, user expectations, country-specific elements, etc. could continue to grow dramatically.