Netflix API : BAPI 2011 Presentation : SF


Published on

This is my presentation from the Business of APIs Conference in SF, held by Mashery (

This talk talks briefly about the history of the Netflix API, then goes into three main categories of scaling:
1. Using the cloud to scale in size and internationally
2. Using Webkit to scale application development in parallel to the flexibility afforded by the API
3. Redesigning the API to improve performance and to downscale the infrastructure as the system scales

When viewing these slides, please note that they are almost entirely image-based, so I have added notes for each slide to detail the talking points.

  • I've heard other users complain about this as well and I think if netflix doesn't iron this out it will share the fate of myspace where a company that does what netflix does but does it better will come along and sweep all of netflix's subscribers off the map and into their pockets. When a user is on the instant streaming portion of the site (which, presumably will be the only part of the site in a few years) they are presented with a kind of rolodex of films. To the end user there is no rhyme or reason as to why they are seeing THESE PARTICULAR films. One might make the assumption that they are selected based on a number of qualifiers for example, quality, budget, production value, language--but still all these things are speculative. It's not uncommon for new technologies to try and supplant an older technology's logic. In this case, the television. The experience of passivity on netflix is merely frustrating though because it is a hybrid of a passive and active experience making one feel more like a leashed dog than anything. I understand the idea of a guided experience but the guiding must happen in a way that is more transparent.
    Are you sure you want to  Yes  No
    Your message goes here
  • Wow! Those speaker notes really make the presentation. I featured this. Thinking a lot about APIs myself nowadays...
    Are you sure you want to  Yes  No
    Your message goes here
  • Nice stuff, Daniel. I think it's the clearest and most compelling case for changing the focus from public to private that I have heard. I'm a big proponent of public APIs (as you know), but it's simply not reasonable to maintain that as a primary focus given the distribution of requests.
    Are you sure you want to  Yes  No
    Your message goes here
  • Most of these slides are just images, so the please view these slides with the Speaker Notes to get all of the context.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • When the Netflix API launchedin 2008, it was to “let 1,000 flowers bloom”. It was exclusively a public API.
  • Some of the many applications produced through the public API…
  • Then streaming started taking off for Netflix, first with computer-based streaming…
  • And then streaming devices began to increase over the years. At first, the devices did not draw from the API. Over time, however, newer devices began to consume the API and some of the older devices have been retrofitted.Now, the public developer community is just another consumer of the API.
  • During the growth of the device strategy and the increase in the API adoption, the API slowly became engrained into the DNA of the engineering culture.Now, the engineering organizational structure reflects this. There are many engineering teams internal to Netflix that produce and manage data and/or algorithmic output.There are a range of engineering teams internal to Netflix that create presentation layers on various devices.The API sits between those two groups, in the critical path for the Netflix streaming service. The API essentially brokers content from inside the firewall to outside.
  • With the emphasis of the API being in the devices, the public developers now represent less than 1% of the total API traffic.
  • As a result, the private, device-centric API is the emphasis of the Netflix API program going forward. The public API is still supported, but not the emphasis.
  • Looking back at this adoption rate, we see atremendous growth in the API. Over an 18 month span, we have gone from under 1B requests per month to over 1B requests per day. With trendlines that look like this, one of the primary issues is scaling the API.
  • And our international expansion will only add complexity and more scaling issues. So, how are we addressing the scale issues?
  • The cloud! Enables rapid scaling with relative ease. Adding new servers, in new locations, take minutes.
  • If our server farm looked like this in 2010, in terms of scale…
  • We would need a server farm like this to serve the increased API traffic. To ramp up this number of servers, it takes systems administrators to acquire and image new boxes, power considerations for data centers, etc. Moreover, adding these servers in data centers for expected spikes results in hardware the has been paid for and deployed, but is not being used.
  • So, instead of going into big server rooms like this one to scale our system…
  • We go into a web page like this one, which is part of our internal cloud management toolset to handle our EC2 infrastructure.
  • And as we continue to expand internationally, through EC2, the API can easily scale up in new regions, closer to the customer base that we are trying to serve, as long as Amazon has a location there.
  • The API has enabled great ability to build new apps
  • The API provides great ability to quickly build device apps. Cloud infrastructure helps those apps scale with the company. To enable more nimble development of the apps themselves, Netflix used Webkit.
  • Netflix Android app is built from the same codebase as the iPhone app. There are key differences, but the iPhone codebase can be leveraged here in ways that a native app cannot.
  • We also need to improve the application.
  • The next phase of improvement is to redesign the API.In essence, while the current API is capable of serving us in the way we need, it is probably no longer the best tool for the job. We believe we can do much better with a new API that is designed for the future of Netflix.
  • We already talked about the tremendous growth in API requests…
  • And one billion requests a day sounds great, doesn’t it?For us, this number is a bit concerning…
  • 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.
  • But for systems that yield output that looks like this…
  • And this…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.
  • So, weare challenging ourselves to redesign the API to see if those same one billion requests could have been 100 million 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.
  • As we decrease overall traffic,our server count that currently looks something like this…
  • Could end up looking more like this. Lower server counts means reduced costs, simpler implementations, etc.
  • The ultimate goal, however, is to help our device apps to run as a fast as possible. And reducing the requests with a less chatty API will improve the overall performance for the devices.
  • Which, in turn, will help keep our customers happy.
  • Netflix API : BAPI 2011 Presentation : SF

    1. Transforming Streaming with the Netflix API<br />By Daniel Jacobson<br />@daniel_jacobson<br /><br /><br />
    2. Netflix <br />API<br />
    3. Netflix <br />API<br />Almost 23,000 flowers <br />Hundreds of devices<br />
    4. API<br />Personalization Engine<br />User Info<br />Movie Metadata<br />Movie Ratings<br />Similar Movies<br />Reviews<br />A/B Test Engine<br />
    5. Netflix API Requests by Audience<br />
    6. Current Emphasis of Netflix<br />
    7. Netflix API : Requests Per Month<br />
    8. AWS Cloud<br />
    9. So, we have a scalable infrastructure… Now what?<br />
    10. Webkit<br /><ul><li>Dynamically update UIs
    11. Control the experience
    12. Share code across devices
    13. Run A/B tests</li></li></ul><li>Android<br />iPhone<br />
    14. And we have a flexible UI.Now what?<br />
    15. Next Step… Redesign the API<br />
    16. Netflix API : Requests Per Month<br />
    17. Growth of the Netflix API<br />Over 1 Billion requests per day<br />(Peaks at about 20,000 requests per second)<br />
    18. <catalog_titles><br /> <number_of_results>1140</number_of_results><br /> <start_index>0</start_index><br /> <results_per_page>10</results_per_page><br /> <catalog_title><br /> <id></id><title short="Star" regular="Star"></title><br /> <box_art small="" <br /> medium="" <br /> large=""></box_art><br /> <link href="" <br />rel="" title="synopsis"></link><br /> <release_year>2001</release_year><br /> <category scheme="" label="NR"></category><br /> <category scheme="" label="Foreign"></category><br /> <link href="" <br />rel="" title="cast"></link><br /><link href="" rel="" title="screen formats"></link<br /> <link href="" rel="" title="languages and audio"></link><br /> <average_rating>1.9</average_rating><br /> <link href="" rel="" title="similars"></link><br /> <link href="" rel="alternate" title="webpage"></link><br /> </catalog_title><br /> <catalog_title><br /> <id></id><title short="Lone Star" regular="Lone Star"></title><br /> <box_art small="" medium="" large=""></box_art><br /> <link href="" rel="" title="synopsis"></link><br /> <release_year>1996</release_year><br /> <category scheme="" label="R"></category><br /> <category scheme="" label="Drama"></category><br /><link href="" rel="" title="awards"></link><br /> <link href="" rel="" title="formats"></link><br /> <link href="" rel="" title="screen formats"></link><br /> <link href="" rel="" title="languages and audio"></link><br /> <average_rating>3.7</average_rating><br /> <link href="" rel="" title="previews"></link><br /> <link href="" rel="" title="similars"></link><br /> <link href="" rel="alternate" title="webpage"></link><br /> </catalog_title><br /></catalog_titles><br />
    19. {"catalog_title":<br />{"id":"",<br />"title":{"title_short":"Rosencrantz and Guildenstern Are Dead",<br />"regular":"Rosencrantz and Guildenstern Are Dead"},<br />"maturity_level":60,<br />"release_year":"1990",<br />"average_rating":3.7,<br />"box_art":{"284pix_w":"",<br />"110pix_w":"",<br />"38pix_w":"",<br />"64pix_w":"",<br />"150pix_w":"",<br />"88pix_w":"",<br />"124pix_w":""},<br />"language":"en",<br />"web_page":"",<br />"tiny_url":""},<br />"meta":{<br />"expand":["@directors","@bonus_materials","@cast","@awards","@short_synopsis","@synopsis","@box_art","@screen_formats","@"links":{"id":"",<br />"languages_and_audio":"",<br />"title":"",<br />"screen_formats":"",<br />"cast":"",<br />"awards":"",<br />"short_synopsis":"",<br />"box_art":"",<br />"synopsis":"",<br />"directors":"",<br />"similars":"",<br />"format_availability":""}<br />}}<br />
    20. Improve Efficiency of API Requests<br />Could it have been 100 million requests per day? Or less?<br />(Assuming everything else remained the same)<br />