This is a presentation that I gave to ESPN's Digital Media team about 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 JacobsonDirector of Engineering - Netflix API at Netflix
RSS feeds are one example of a commonly used API, albeit a very simple one.
Podcasts are another example of an API, extended from RSS.
In addition to the APIs that ESPN currently offers online, ESPN is also consuming perhaps the most popular API – Google Maps.
Netflix has a series of engineering teams that focus on very specific problems around movie and user information. That information needs to get to the hundreds of devices where Netflix users enjoy our streaming service. That information gets through through the API.
Visual representation of the “1,000 flowers” model.
Some of the apps that have been built by the open developer community (1,000 flowers).
Then streaming started taking off for Netflix
And the API started supporting more and more internal device implementations
Now, we have hundreds of devices being run off the API, driving tremendous business growth.
Including the Android app, which just launched in May, 2011.
And the Netflix API traffic has gone through the roofAveraging over 20B requests per monthWith peak traffic over 18,000 requests per second
And the proportion of API requests coming to the Netflix API through the public has gone way down.The 1,000 flowers represent less than ½ a percent of the total API traffic
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?
Especially when features differ from device to device.
The differences across the devices call into question how to develop effectively and efficiently for all of them. This raises a decision on how to implement for the devices. For us, that became a question about WebKit or native app implementations. Most of our implementations are WebKit-based.
iPhone and Android apps are both WebKit implementations. In fact, the Netflix Android app is derivative 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.
So, we have seen tremendous growth in API consumption.
Metrics like 20B requests per month sound great, don’t they? The reality is that this number is 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.
Other media organizations are employing different techniques to generate more traffic. The New York Times, for example, is paginating their article pages which creates more potential page views and therefore ad impressions.
But for systems that yield output that looks like this, 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.
We are challenging ourselves to redesign the API to see if those same 20 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.
So, when redesigning the API, we want to target it towards to key audiences. For us, the key audiences are our devices.
Once it is designed for our future, we will trickle it down to the 1000 flowers and/or other audiences.
And we don’t just plan to design the API to be for our current audience. Instead, we plan to dream bigger and design the system for the audience that we want.That doesn’t mean we should implement today the system we want for the dream audience. It just means the design should allow for the system to scale to that audience.
For Netflix, we have designed our server architecture, using AWS, to be highly scalable. The API redesign will help us scale the software better to handle this scaling more effectively and efficiently.