Lessons in API Deployment From Netflix

by Kin Lane on 06/10/2011

I've heard this story several times now, but I think its a story worth telling over and over.

It is the story of the Netflix API and the lessons they learned along the way. Not every API owner will be operating at the scale of Netflix, but the lessons are universal.

It all started when Netflix set out to build an API, where the original charter was:

Expose Netflix metadata and services to the public developer community to "let 1,000 flowers bloom". That community will build rich and exciting new tools and services to improve the value of Netflix to our customers.

The concept of 1,000 flowers refers to the public community Netflix was targeting with the API, where ideas and applications would flower from each developer.

Fast forward a couple years, and the API has been successful, with growth looking something like this:

However the innovation did not come from where the original charter identified. The API delivered the greatest value from these groups (in order of importance):

Internal Engineering Teams
- Netflix Product Owners
- Netflix Developers
Partner Relationships
- External Device Manufacturers
- Public Developer Community
1,000 Flowers

Even with over 18K public developers using the API, it accounts for less than .5% of the traffic to the API. With internal teams and external device manufacturers accounting for the largest consumption.

With these lessons in mind, the new charter for the Netflix API goes something like this:

Build and maintain an infinitely scalable data distribution pipeline for getting metadata and services from internal Netflix systems to streaming client apps on all platforms in the format and / or deliver method that is most optimal for each app and platform.

And moving forward, any future architecture will focus on supporting the key target audience first with a trickle down of features to the other audience segments.

Key lessons you can take away from the Netflix API deployment:

Understand the target audience of your API
Design for your most critical audiences first
Internalize the API as part of your companies engineering DNA
if you build a public API, make sure and help them bloom

Its easy to get caught up in the hype and buzz around having a public API, where you should be focusing on consuming your API internally, then sharing that value with key partners, and then when ready, take what you've learned and try growing thousands of flowers.

(Thanks to Daniel Jacobson for the images and material from his Mashery presentation)