0
Techniques for Scaling the       Netflix API      By Daniel Jacobson       @daniel_jacobson    djacobson@netflix.com      ...
Techniques for Scaling the Netflix API                      Agenda•   History of the Netflix API•   The Cloud•   Developme...
Techniques for Scaling the Netflix API                      Agenda•   History of the Netflix API•   The Cloud•   Developme...
Netflix API
Netflix API Requests by Audience          At Launch In 2008                              Netflix Devices                  ...
Netflix API
Netflix API Requests by Audience   At Launch                         Today               Netflix Devices               Ope...
Public API             Private API
Current Emphasis of Netflix API                         Netflix Devices
Techniques for Scaling the Netflix API                      Agenda•   History of the Netflix API•   The Cloud•   Developme...
Discovery
Discovery
Streaming
Netflix API Powers Discovery
Netflix API : Requests Per Month                       35                       30                       25Requests in Bil...
Netflix API : Requests Per Month                       35                       30                       25Requests in Bil...
AWS Cloud
Autoscaling
Autoscaling
Techniques for Scaling the Netflix API                      Agenda•   History of the Netflix API•   The Cloud•   Developme...
Development / Testing     Philosophy    Act fast, react fast
That Doesn’t Mean We Don’t Test•   Unit tests•   Functional tests•   Regression scripts•   Continuous integration•   Capac...
Development         Contiuous                                 Run Unit Tests(Feature & Test)   Integration   Perform      ...
Cloud-Based Deployment Techniques
API Requests from                   the Internet                                                           Problem!Current...
API Requests from                   the InternetCurrent CodeIn Production
API Requests from                   the InternetCurrent Code                              New CodeIn Production           ...
API Requests from                           the Internet      Old Code                              Current CodePrepared F...
API Requests from                                 the Internet         Old Code                                    New Cod...
API Requests from                   the InternetCurrent CodeIn Production
API Requests from                   the InternetCurrent Code                              New CodeIn Production           ...
API Requests from                           the Internet      Old Code                              Current CodePrepared F...
API Requests from   the Internet                    Current Code                    In Production
Development                          Continuous                   Run Unit Tests(Feature & Test)                     Integ...
Techniques for Scaling the Netflix API                      Agenda•   History of the Netflix API•   The Cloud•   Developme...
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
Circuit Breaker Dashboard
Call Volume and Health / Last 10 Seconds
Call Volume / Last 2 Minutes
Successful Requests
Successful, But Slower Than Expected
Short-Circuited Requests, Delivering Fallbacks
Timeouts, Delivering Fallbacks
Thread Pool & Task Queue Full, Delivering Fallbacks
Exceptions, Delivering Fallbacks
# + # + # + # / (# + # + # + # + #) = Error Rate                                                   Error Rate
Status of Fallback Circuit
Requests per Second, Over Last 10 Seconds
SLA Information
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
APIPersonaliz                          Movie     Movie     Similar             A/B Test  ation      User Info             ...
API                         FallbackPersonaliz                                Movie     Movie     Similar             A/B ...
API                         FallbackPersonaliz                                Movie     Movie     Similar             A/B ...
Techniques for Scaling the Netflix API                      Agenda•   History of the Netflix API•   The Cloud•   Developme...
Netflix API
Netflix API Requests by Audience     Supporting Streaming Devices Today                                      Netflix Devic...
Redesign the API
Netflix API : Requests Per Month                       35                       30                       25Requests in Bil...
Growth of the Netflix APIOver 30 Billion requests per month    (Peaks at about 20,000 requests per second)
<catalog_titles> <number_of_results>1140</number_of_results> <start_index>0</start_index> <results_per_page>10</results_pe...
{"catalog_title":{"id":"http://api.netflix.com/catalog/titles/movies/60034967","title":{"title_short":"Rosencrantz and Gui...
Improve Efficiency of API RequestsCould it have been 5 billion requests per month? Or less?             (Assuming everythi...
Netflix API : Requests Per Month                      35                      30                      25Request in Billion...
Netflix API : Requests Per Month                      35                      30                      25Request in Billion...
API Billionaires Club13 billion API calls / day (May 2011)Over 260 billion objects stored in S3 (January 2011)5 billion AP...
API Billionaires Club13 billion API calls / day (May 2011)Over 260 billion objects stored in S3 (January 2011)5 billion AP...
Two Major Objective for             API Redesign• Improve performance for devices  – Minimize network traffic (one API cal...
Current Client / Server InteractionCLIENT APPS        API SERVER                                 AUTH                     ...
Future Client / Server InteractionCLIENT APPS       API SERVER                  CUSTOM SCRIPTING TIER                     ...
Custom Scripting Tier InteractionCLIENT APPS               API SERVER                                        AUTH         ...
For More Titles From a List
Generic API InteractionCLIENT APP                API SERVER                                        AUTH                GEN...
Technologies                               AUTH                              CONFIG                               TIME    ...
API Production Servers  Cassandra Cluster                         UI Engineers
Active  1      2           3               4                   5    SCRIPT REPOSITORY            6  (DYNAMICDEPLOYMENT)   ...
Active  1      2           3               4                   5    SCRIPT REPOSITORY            6  (DYNAMIC              ...
1      2          3              4                              Active                  5    SCRIPT REPOSITORY           6...
If you are interested in helping us solve these       problems, please contact me at:           Daniel Jacobson          d...
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
Upcoming SlideShare
Loading in...5
×

Techniques for Scaling the Netflix API - QCon SF

4,589

Published on

This presentation was from QCon SF 2011. In these slides I discuss various techniques that we use to scale the API. I also discuss in more detail our effort around redesigning the API.

Published in: Technology, Business
1 Comment
18 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,589
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
126
Comments
1
Likes
18
Embeds 0
No embeds

No notes for slide
  • When the Netflix API launched three years ago, it was to “let 1,000 flowers bloom”. Today, that API still exists with almost 23,000 flowers.
  • At that time, it was exclusively a public API.
  • Some of the apps developed by the 1,000 flowers.
  • Then streaming started taking off for Netflix, first with computer-based streaming… At that time, it was still experimental and did not draw from the API.
  • But over time, as we added more devices, they started drawing their metadata from the API. Today, almost all of our devices are powered by the API.
  • As a result, today’s consumption is almost entirely from private APIs that service the devices. The Netflix devices account for 99.7% of the API traffic while the public API represents only about .3%.
  • The Netflix API represents the iceberg model for APIs. That is, public APIs represent a relatively small percentage of the value for the company, but they are typically the most visible part of the API program. They equate to the small part of the iceberg that is above water, in open sight. Conversely, the private APIs that drive web sites, mobile phones, device implementations, etc. account for the vast majority of the value for many companies, although people outside of the company often are not aware of them. These APIs equate to the large, hard to see mass of ice underwater. In the API space, most companies get attracted to the tip of the iceberg because that is what they are aware of. As a result, many companies seek to pursue a public API program. Over time, however, after more inspection into the value propositions of APIs, it becomes clear to many that the greatest value is in the private APIs.
  • As a result, the current emphasis for the Netflix API is on the majority case… supporting the Netflix
  • There are basically two types of interactions between Netflix customers and our streaming application… Discovery and Streaming.
  • Discovery is basically any event with a title other than streaming it. That includes browsing titles, looking for something watch, etc.
  • It also includes actions such as rating the title, adding it to your instant queue, etc.
  • Once the customer has identified a title to watch through the Discovery experience, the user can then play that title. Once the Play button is selected, the customer is sent to a different internal service that focuses on handling the streaming. That streaming service also interacts with our CDNs to actually deliver the streaming bits to the device for playback.
  • The API powers the Discovery experience. The rest of these slides will only focus on Discovery, not Streaming.
  • As Discovery events grow, so does the growth of the Netflix API. Discovery continues to grow for a variety of reasons, including more devices, more customers, richer UI experiences, etc.
  • As API traffic grows, so do the infrastructural needs. The more requests, the more servers we need, the more time spent supporting those servers, the higher the costs associated with this support, etc.
  • And our international expansion will only add complexity and more scaling issues.
  • The traditional model is to have systems administrators go into server rooms like this one to build out new servers, etc.
  • Rather than relying on data centers, we have moved everything to the cloud! Enables rapid scaling with relative ease. Adding new servers, in new locations, take minutes. And this is critical when the service needs to grow from 1B requests a month to 1B requests a day in a year.
  • Instead of going into server rooms, we go into a web page like this one. Within minutes, we can spin up new servers to support growing demands.
  • Throughautoscaling in the cloud, we can also dynamically grow our server farm in concert with the traffic that we receive.
  • So, instead of buying new servers based on projected spikes in traffic and having systems administrators add them to the farm, the cloud can dynamically and automatically add and remove servers based on need.
  • And as we continue to expand internationally, we 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 near there.
  • As a general practice, Netflix focuses on getting code into production as quickly as possible to expose features to new audiences.
  • That said, we do spend a lot of time testing. We have just adopted some new techniques to help us learn more about what the new code will look like in production.
  • Prior to these new changes, our flow looked something like this…
  • That flow has changed with the addition of new techniques, such as canary deployments and what we call red/black deployments.
  • The canary deployments are comparable to canaries in coal mines. We have many servers in production running the current codebase. We will then introduce a single (or perhaps a few) new servers into production running new code. Monitoring the canary servers will show what the new code will look like in production.
  • If the canary shows errors, we pull it/them down, re-evaluate the new code, debug it, etc. We will then repeat the process until the analysis of canary servers look good.
  • If the new code looks good in the canary, we can then use a technique that we call Red/Black Deployments to launch the code. Start with Red, where production code is running. Fire up a new set of servers (Black) equal to the count in Red with the new code.
  • Then switch the pointer to have external requests draw from the Black servers.
  • If a problem is encountered from the Black servers, it is easy to rollback quickly by switching the pointer back to Red. We will then re-evaluate the new code, debug it, etc.
  • Once we have debugged the code, we will put another canary up to evaluate the new changes in production.
  • If the new code looks good in the canary, we can then bring up another set of servers with the new code.
  • Then we will switch production traffic to the new code.
  • Then switch the pointer to have external requests draw from the Black servers. If everything still looks good, we disable the Red servers and the new code becomes the new red servers.
  • So, the development and testing flow now looks more like this…
  • At Netflix, we have a range of engineering teams who focus on specific problem sets. Some teams focus on creating rich presentation layers on various devices. Others focus on metadata and algorithms. For the streaming application to work, the metadata from the services needs to make it to the devices. That is where the API comes in. The API essentially acts as a broken, moving the metadata from inside the Netflix system to the devices.
  • Given the position of the API within the overall system, the API depends on a large number of underlying systems (only some of which are represented here). Moreover, a large number of devices depend on the API (only some of which are represented here). Sometimes, one of these underlying systems experiences an outage.
  • In the past, such an outage could result in an outage in the API.
  • And if that outage cascades to the API, it is likely to have some kind of substantive impact on the devices. The challenge for the API team is to be resilient against dependency outages, to ultimately insulate Netflix customers from low level system problems.
  • To achieve this, we implemented a series of circuit breakers for each library that we depend on. Each circuit breaker controls the interaction between the API and that dependency. This image is a view of the dependency monitor that allows us to view the health and activity of each dependency. This dashboard is designed to give a real-time view of what is happening with these dependencies (over the last two minutes). We have other dashboards that provide insight into longer-term trends, day-over-day views, etc.
  • This is a view of asingle circuit.
  • This circle represents the call volume and health of the dependency over the last 10 seconds. This circle is meant to be a visual indicator for health. The circle is green for healthy, yellow for borderline, and red for unhealthy. Moreover, the size of the circle represents the call volumes, where bigger circles mean more traffic.
  • The blue line represents the traffic trends over the last two minutes for this dependency.
  • The green number shows the number of successful calls to this dependency over the last two minutes.
  • The yellow number shows the number of latent calls into the dependency. These calls ultimately return successful responses, but slower than expected.
  • The blue number shows the number of calls that were handled by the short-circuited fallback mechanisms. That is, if the circuit gets tripped, the blue number will start to go up.
  • The orange number shows the number of calls that have timed out, resulting in fallback responses.
  • The purple number shows the number of calls that fail due to queuing issues, resulting in fallback responses.
  • The red number shows the number of exceptions, resulting in fallback responses.
  • The error rate is calculated from the total number of error and fallback responses divided by the total number calls handled.
  • If the error rate exceeds a certain number, the circuit to the fallback scenario is automatically opened. When it returns below that threshold, the circuit is closed again.
  • The dashboard also shows host and cluster information for the dependency.
  • As well as information about our SLAs.
  • So, going back to the engineering diagram…
  • If that same service fails today…
  • We simply disconnect from that service.
  • And replace it with an appropriate fallback.
  • Keeping our customers happy, even if the experience may be slightly degraded. It is important to note that different dependency libraries have different fallback scenarios. And some are more resilient than others. But the overall sentiment here is accurate at a high level.
  • As discussed earlier, the API was originally built for the 1,000 flowers. Accordingly, today’s API design is very much grounded in the same principles for that same audience.
  • But the audience of the API today is dramatically different.
  • With the emphasis of the API program being on the large mass underwater – the private API.
  • As a result, the current API is no longer the right tool for the job. We need a new API, designed for the present and the future. The following slides talk more about the redesign of the Netflix API to better meet the needs of the key audiences.
  • We already talked about the tremendous growth in API requests…
  • Metrics like 30B requests per month sound great, don’t they? The reality is that this number is concerning…
  • For web sites, like NPR, where page views create ad impressions and ad impressions generate revenue, 30B requests would be amazing.
  • But for systems that yield output that looks like this...
  • Or 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.
  • We are challenging ourselves to redesign the API to see if those same 30B 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.
  • Given the same growth charts in the API, it would be great to imagine the traffic patterns being the blue bars instead of the red ones (assuming the customer usage and user experiences remain the same).
  • Similarly, with lower traffic levels for the same user experience, server and administration complexity and costs go down as well.
  • To state the goal another way, John Musser maintains a list of the API Billionaires. Netflix has a pretty lofty position in that club.
  • We aspire to no longer be in that exclusive company. That is one of the things the redesign strives for.
  • Today, the devices call back to the API in a mostly synchronous way to retrieve granular metadata needed to start up the client UI. That model requires a large number of network transactions which are the most expensive part of the overall interaction.
  • We want to break the interaction model into two types of interactions. Custom calls and generic calls.
  • For highly complex or critical interfaces, we want the device to make a single call to the API to a custom endpoint. Behind that endpoint will be a script that the UI teams maintain. That script is the traffic cop for gathering and formatting the metadata needed for that UI. The script will call to backend services to get metadata, but in this model, much of this will be concurrent and progressively rendered to the devices.
  • One way to think of it is to imagine a full grid of movies/TV shows as part of a Netflix UI. The red box represents the viewable area of the grid when the screen loads. In today’s REST-ful resource model, the device needs to make calls for the individual lists, then populate the individual titles with distinct calls for each title. Granted, in today’s model, the are some asynchronous calls and some of them are also performed in bulk. But this still demonstrates the chatty nature of this REST-ful API design.
  • Alternatively, we believe that the custom script could easily return the desiredviewables for each list in one payload much more efficiently.
  • Moreover, this model can return any payload, filling out any portions of the grid structure, in that single response. Now, we are not likely going to want to populate a grid in this way, but it is possible given the highly customizable nature of this model.
  • But once we populate the complex start-up screens through the custom scripting tier, the interactions become much more predictable and device-agnostic. If you want to extend the movies in a given row, you don’t need a custom script. That is why we are exposing the Generic API as well.
  • To populate the grid with more titles for more rows, it is a simple call to get more titles.
  • The call pattern looks like this for the Generic API. Notice, there is no need for some of the session-start requests when using the Generic API.
  • For this model, the technology stack is pretty simple. The client apps have their own languages designed for that particular device. The overall API server codebase is Java. And the custom scripts will be written in Groovy and compiled into the same JVM as the backend API code. This should help with overall performance and library sharing for more complex scripting operations.
  • To publish new scripts to the system, UI engineers will publish the script to Perforce for code management. Then it will be pushed up to a Cassandra cluster in AWS, which acts as a script repository and management system. Every 30 seconds or so, a job will scan the Cassandra cluster looking for new scripts. For all new scripts, they will be pushed to the full farm of API servers to be compiled into the JVM.
  • From the device perspective, there could be many scripts for a given endpoint, only one of which is active at a given time. In this case, the iPad is running off of script #2.
  • New scripts can be dynamically added at any time by any team (most often by the UI engineers). The new script (script 7) will arrive in an inactive state. At that time, the script can be tested from a production server before running the device off of it.
  • When the script looks good and is ready to go live, a configuration change is made and script 7 becomes active immediately across the full server farm.
  • All of these changes in our redesign effort are designed to help the apps and the UI engineers run faster.
  • And achieving those goals will help us keep our customers happy.
  • Transcript of "Techniques for Scaling the Netflix API - QCon SF"

    1. 1. Techniques for Scaling the Netflix API By Daniel Jacobson @daniel_jacobson djacobson@netflix.com QCon SF 2011
    2. 2. Techniques for Scaling the Netflix API Agenda• History of the Netflix API• The Cloud• Development and Testing• Resiliency• Future of the Netflix API
    3. 3. Techniques for Scaling the Netflix API Agenda• History of the Netflix API• The Cloud• Development and Testing• Resiliency• Future of the Netflix API
    4. 4. Netflix API
    5. 5. Netflix API Requests by Audience At Launch In 2008 Netflix Devices Open API Developers
    6. 6. Netflix API
    7. 7. Netflix API Requests by Audience At Launch Today Netflix Devices Open API Developers
    8. 8. Public API Private API
    9. 9. Current Emphasis of Netflix API Netflix Devices
    10. 10. Techniques for Scaling the Netflix API Agenda• History of the Netflix API• The Cloud• Development and Testing• Resiliency• Future of the Netflix API
    11. 11. Discovery
    12. 12. Discovery
    13. 13. Streaming
    14. 14. Netflix API Powers Discovery
    15. 15. Netflix API : Requests Per Month 35 30 25Requests in Billions 20 15 10 5 -
    16. 16. Netflix API : Requests Per Month 35 30 25Requests in Billions 20 15 10 5 -
    17. 17. AWS Cloud
    18. 18. Autoscaling
    19. 19. Autoscaling
    20. 20. Techniques for Scaling the Netflix API Agenda• History of the Netflix API• The Cloud• Development and Testing• Resiliency• Future of the Netflix API
    21. 21. Development / Testing Philosophy Act fast, react fast
    22. 22. That Doesn’t Mean We Don’t Test• Unit tests• Functional tests• Regression scripts• Continuous integration• Capacity planning• Load / Performance tests
    23. 23. Development Contiuous Run Unit Tests(Feature & Test) Integration Perform Deploy to Run Functional Integration Staging Env Tests Tests Deploy to Customers
    24. 24. Cloud-Based Deployment Techniques
    25. 25. API Requests from the Internet Problem!Current CodeIn Production Single Canary Instance To Test New Code with Production Traffic (typically around 1-5% of traffic)
    26. 26. API Requests from the InternetCurrent CodeIn Production
    27. 27. API Requests from the InternetCurrent Code New CodeIn Production Getting Prepared for Production
    28. 28. API Requests from the Internet Old Code Current CodePrepared For Rollback In Production
    29. 29. API Requests from the Internet Old Code New CodeRolled Back into Production Out of Production
    30. 30. API Requests from the InternetCurrent CodeIn Production
    31. 31. API Requests from the InternetCurrent Code New CodeIn Production Getting Prepared for Production
    32. 32. API Requests from the Internet Old Code Current CodePrepared For Rollback In Production
    33. 33. API Requests from the Internet Current Code In Production
    34. 34. Development Continuous Run Unit Tests(Feature & Test) Integration Run Deploy to Run Functional Integration Staging Env Tests Tests PerformDeploy Canary Canary Instance(s) Analysis Deploy to Perform Black Deploy Black Customers Analysis Instances
    35. 35. Techniques for Scaling the Netflix API Agenda• History of the Netflix API• The Cloud• Development and Testing• Resiliency• Future of the Netflix API
    36. 36. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    37. 37. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    38. 38. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    39. 39. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    40. 40. Circuit Breaker Dashboard
    41. 41. Call Volume and Health / Last 10 Seconds
    42. 42. Call Volume / Last 2 Minutes
    43. 43. Successful Requests
    44. 44. Successful, But Slower Than Expected
    45. 45. Short-Circuited Requests, Delivering Fallbacks
    46. 46. Timeouts, Delivering Fallbacks
    47. 47. Thread Pool & Task Queue Full, Delivering Fallbacks
    48. 48. Exceptions, Delivering Fallbacks
    49. 49. # + # + # + # / (# + # + # + # + #) = Error Rate Error Rate
    50. 50. Status of Fallback Circuit
    51. 51. Requests per Second, Over Last 10 Seconds
    52. 52. SLA Information
    53. 53. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    54. 54. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    55. 55. APIPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    56. 56. API FallbackPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    57. 57. API FallbackPersonaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
    58. 58. Techniques for Scaling the Netflix API Agenda• History of the Netflix API• The Cloud• Development and Testing• Resiliency• Future of the Netflix API
    59. 59. Netflix API
    60. 60. Netflix API Requests by Audience Supporting Streaming Devices Today Netflix Devices Open API Developers
    61. 61. Redesign the API
    62. 62. Netflix API : Requests Per Month 35 30 25Requests in Billions 20 15 10 5 -
    63. 63. Growth of the Netflix APIOver 30 Billion requests per month (Peaks at about 20,000 requests per second)
    64. 64. <catalog_titles> <number_of_results>1140</number_of_results> <start_index>0</start_index> <results_per_page>10</results_per_page> <catalog_title> <id>http://api.netflix.com/catalog/titles/movies/60021896</id><title short="Star" regular="Star"></title> <box_art small="http://alien2.netflix.com/us/boxshots/tiny/60021896.jpg" medium="http://alien2.netflix.com/us/boxshots/small/60021896.jpg" large="http://alien2.netflix.com/us/boxshots/large/60021896.jpg"></box_art> <link href="http://api.netflix.com/catalog/titles/movies/60021896/synopsis" rel="http://schemas.netflix.com/catalog/titles/synopsis" title="synopsis"></link> <release_year>2001</release_year> <category scheme="http://api.netflix.com/catalog/titles/mpaa_ratings" label="NR"></category> <category scheme="http://api.netflix.com/categories/genres" label="Foreign"></category> <link href="http://api.netflix.com/catalog/titles/movies/60021896/cast" rel="http://schemas.netflix.com/catalog/people.cast" title="cast"></link><link href="http://api.netflix.com/catalog/titles/movies/60021896/screen_formats" rel="http://schemas.netflix.com/catalog/titles/screen_formats" title="screenformats"></link <link href="http://api.netflix.com/catalog/titles/movies/60021896/languages_and_audio" rel="http://schemas.netflix.com/catalog/titles/languages_and_audio"title="languages and audio"></link> <average_rating>1.9</average_rating> <link href="http://api.netflix.com/catalog/titles/movies/60021896/similars" rel="http://schemas.netflix.com/catalog/titles.similars" title="similars"></link> <link href="http://www.netflix.com/Movie/Star/60021896" rel="alternate" title="webpage"></link> </catalog_title> <catalog_title> <id>http://api.netflix.com/catalog/titles/movies/17985448</id><title short="Lone Star" regular="Lone Star"></title> <box_art small="http://alien2.netflix.com/us/boxshots/tiny/17985448.jpg" medium="http://alien2.netflix.com/us/boxshots/small/17985448.jpg" large=""></box_art> <link href="http://api.netflix.com/catalog/titles/movies/17985448/synopsis" rel="http://schemas.netflix.com/catalog/titles/synopsis" title="synopsis"></link> <release_year>1996</release_year> <category scheme="http://api.netflix.com/catalog/titles/mpaa_ratings" label="R"></category> <category scheme="http://api.netflix.com/categories/genres" label="Drama"></category><link href="http://api.netflix.com/catalog/titles/movies/17985448/awards" rel="http://schemas.netflix.com/catalog/titles/awards" title="awards"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/format_availability" rel="http://schemas.netflix.com/catalog/titles/format_availability"title="formats"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/screen_formats" rel="http://schemas.netflix.com/catalog/titles/screen_formats" title="screenformats"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/languages_and_audio" rel="http://schemas.netflix.com/catalog/titles/languages_and_audio"title="languages and audio"></link> <average_rating>3.7</average_rating> <link href="http://api.netflix.com/catalog/titles/movies/17985448/previews" rel="http://schemas.netflix.com/catalog/titles/previews" title="previews"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/similars" rel="http://schemas.netflix.com/catalog/titles.similars" title="similars"></link> <link href="http://www.netflix.com/Movie/Lone_Star/17985448" rel="alternate" title="webpage"></link> </catalog_title></catalog_titles>
    65. 65. {"catalog_title":{"id":"http://api.netflix.com/catalog/titles/movies/60034967","title":{"title_short":"Rosencrantz and Guildenstern Are Dead","regular":"Rosencrantz and Guildenstern Are Dead"},"maturity_level":60,"release_year":"1990","average_rating":3.7,"box_art":{"284pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/ghd/60034967.jpg","110pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/large/60034967.jpg","38pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/tiny/60034967.jpg","64pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/small/60034967.jpg","150pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/150/60034967.jpg","88pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/88/60034967.jpg","124pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/124/60034967.jpg"},"language":"en","web_page":"http://www.netflix.com/Movie/Rosencrantz_and_Guildenstern_Are_Dead/60034967","tiny_url":"http://movi.es/ApUP9"},"meta":{"expand":["@directors","@bonus_materials","@cast","@awards","@short_synopsis","@synopsis","@box_art","@screen_formats","@"links":{"id":"http://api.netflix.com/catalog/titles/movies/60034967","languages_and_audio":"http://api.netflix.com/catalog/titles/movies/60034967/languages_and_audio","title":"http://api.netflix.com/catalog/titles/movies/60034967/title","screen_formats":"http://api.netflix.com/catalog/titles/movies/60034967/screen_formats","cast":"http://api.netflix.com/catalog/titles/movies/60034967/cast","awards":"http://api.netflix.com/catalog/titles/movies/60034967/awards","short_synopsis":"http://api.netflix.com/catalog/titles/movies/60034967/short_synopsis","box_art":"http://api.netflix.com/catalog/titles/movies/60034967/box_art","synopsis":"http://api.netflix.com/catalog/titles/movies/60034967/synopsis","directors":"http://api.netflix.com/catalog/titles/movies/60034967/directors","similars":"http://api.netflix.com/catalog/titles/movies/60034967/similars","format_availability":"http://api.netflix.com/catalog/titles/movies/60034967/format_availability"}}}
    66. 66. Improve Efficiency of API RequestsCould it have been 5 billion requests per month? Or less? (Assuming everything else remained the same)
    67. 67. Netflix API : Requests Per Month 35 30 25Request in Billions 20 15 10 5 0
    68. 68. Netflix API : Requests Per Month 35 30 25Request in Billions 20 15 10 5 0
    69. 69. API Billionaires Club13 billion API calls / day (May 2011)Over 260 billion objects stored in S3 (January 2011)5 billion API calls / day (April 2010)5 billion API calls / day (October 2009)1 billion API calls / day (October 2011)8 billion API calls / month (Q3 2009)3.2 billion API-delivered stories / month (October2011)3 billion API calls / month (March 2009) Courtesy of John Musser, ProgrammableWeb
    70. 70. API Billionaires Club13 billion API calls / day (May 2011)Over 260 billion objects stored in S3 (January 2011)5 billion API calls / day (April 2010)5 billion API calls / day (October 2009)1 billion API calls / day (October 2011)8 billion API calls / month (Q3 2009)3.2 billion API-delivered stories / month (October2011)3 billion API calls / month (March 2009) Courtesy of John Musser, ProgrammableWeb
    71. 71. Two Major Objective for API Redesign• Improve performance for devices – Minimize network traffic (one API call, if possible) – Only deliver bytes that are needed• Improve ability for device teams to rapidly innovate – Customized request/response patterns per device – Deployment is independent from API schedules
    72. 72. Current Client / Server InteractionCLIENT APPS API SERVER AUTH SETUP TIME QUEUE LISTS LIST ( i ) TITLES
    73. 73. Future Client / Server InteractionCLIENT APPS API SERVER CUSTOM SCRIPTING TIER GENERIC API
    74. 74. Custom Scripting Tier InteractionCLIENT APPS API SERVER AUTH CUSTOM SCRIPTING SETUP TIER TIME PS3 HOME QUEUE SCREEN CUSTOM LISTS ENDPOINT LIST ( i ) Owned and operated by the UI teams TITLES
    75. 75. For More Titles From a List
    76. 76. Generic API InteractionCLIENT APP API SERVER AUTH GENERIC CONFIG SCRIPT TIME SIMPLE QUEUE CATALOG REQUEST TO API LISTS LIST ( i ) Owned and operated by the API team TITLES
    77. 77. Technologies AUTH CONFIG TIME GROOVY SIMPLE CLIENT COMPILED CATALOG JAVAQUEUE REQUESTLANGUAGE INTO TO API LOLOMO LISTS JVM LIST ( i ) TITLES
    78. 78. API Production Servers Cassandra Cluster UI Engineers
    79. 79. Active 1 2 3 4 5 SCRIPT REPOSITORY 6 (DYNAMICDEPLOYMENT) API SERVER APPLICATION CODE (REQUIRES API CODE PUSHES)
    80. 80. Active 1 2 3 4 5 SCRIPT REPOSITORY 6 (DYNAMIC 7DEPLOYMENT) API SERVER APPLICATION CODE (REQUIRES API CODE PUSHES)
    81. 81. 1 2 3 4 Active 5 SCRIPT REPOSITORY 6 (DYNAMIC 7DEPLOYMENT) API SERVER APPLICATION CODE (REQUIRES API CODE PUSHES)
    82. 82. If you are interested in helping us solve these problems, please contact me at: Daniel Jacobson djacobson@netflix.com @daniel_jacobsonhttp://www.linkedin.com/in/danieljacobson http://www.slideshare.net/danieljacobson
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×