Netflix Play API: Building an Evolutionary Architecture

Netflix Play API: Building an Evolutionary Architecture

  • January 21, 2019
Table of Contents

Netflix Play API: Building an Evolutionary Architecture

At QCon SF, Suudhan Rangarajan presented ‘Netflix Play API: Why We Built an Evolutionary Architecture’. Key takeaways from the talk included: services that have a single identity/responsibility are easier to maintain and upgrade; engineers should spend time identifying core decisions that need to be made when building a service, and determine whether these are ‘Type 1’ or ‘Type 2’ decisions which require thorough deliberation or rapid experimentation, respectively; and designing an ‘evolutionary architecture’, using tools like fitness functions, provides many benefits. Rangarajan, senior software engineer at Netflix, began the presentation by talking about two key business milestones within Netflix in 2016 that also had a large engineering impact.

The first was the release of ‘#netflixeverywhere’ in January, which enabled customers in many countries where Netflix was previously not available to now signup and watch content. The second milestone was the release of new ‘Download & Go’ functionality in November, which provided the ability for customers to download content to a device for offline viewing. Both of these releases put an increased strain on the ‘Play API’ that was, amongst other tasks, responsible for starting the streaming of content to customers.

This resulted in several service outages, and also a decrease in deployment frequency and an increase in rollbacks, which, as stated by Forsgren, Humble and Kim in their book ‘Accelerate’ are key metrics correlated with software delivery performance.

Source: infoq.com

Share :
comments powered by Disqus

Related Posts

Fitness function-driven development

Fitness function-driven development

Test-driven development, or TDD, involves writing tests first then developing the minimal code needed to pass the tests. TDD is an established practice for feature development that can improve code quality and test coverage. What about other, non-functional requirements such as scalability, reliability, observability, and other architectural “-ilities”?

Read More