From Monolith to the Cloud

Almost every software company starts with a monolith: a single deployable program where all the features — sign-up, billing, the movie catalog, playback, recommendations — live in one codebase and run as one process. In Netflix's early streaming days, one large application, running in Netflix's own physical datacenter, did nearly everything.

A monolith is not a mistake. When a product is young, one codebase is the simplest thing that works: one place to write code, one thing to deploy, one database to reason about. The trouble only shows up later, at scale, and it shows up in two ways — how the system fails and how fast teams can move.

The diagram shows the whole product as one box over one database. Everything shares the same fate: if that database or that process goes down, the entire service goes down. That single-point-of-failure risk is not theoretical, as the next section shows.

In August 2008, Netflix suffered a major database corruption event. A problem in the central database took down its ability to ship DVDs for three days. The company has spoken about this event publicly ever since as the turning point in its engineering history — the moment it decided that owning a single big datacenter, with a single vertically-scaled database at the center, was a liability it could not accept.

Two lessons came out of that outage:

• Vertical scaling has a ceiling and a blast radius. Making one machine bigger (more CPU, more memory — "scaling up") eventually stops working, and while it works, one failure takes everything with it.
• Reliability has to be designed in, not bolted on. You cannot make a single central component "not fail." You have to build a system that keeps working when components fail — that expects failure as normal.

These lessons pointed Netflix toward two big moves at once: get out of its own datacenter, and break the monolith apart.

Starting around 2008 and continuing for roughly seven years, Netflix migrated off its own datacenter and onto Amazon Web Services (AWS) — a public cloud, meaning computing capacity (servers, storage, databases) rented on demand over the internet instead of machines you buy and rack yourself. The migration finished in 2016, when Netflix shut down its last datacenter.

The cloud mattered for reasons beyond "someone else runs the hardware":

• Horizontal scaling. Instead of one giant machine, run many small interchangeable machines ("scaling out"). Add capacity by adding instances; lose one and the rest carry on.
• Redundancy across zones. Spread the system across independent failure domains (AWS regions and availability zones) so no single facility outage is fatal.
• Elasticity. Netflix's traffic swings enormously between a quiet weekday morning and a Friday-night premiere. Renting capacity that grows and shrinks fits that shape far better than buying for the peak and idling the rest of the time.

But the cloud alone does not break a monolith. You can run one giant program on rented servers and still have one giant program. The deeper change was architectural.

To get real reliability and team velocity, Netflix broke the monolith into a Service-Oriented Architecture (SOA) — and, in its finer-grained form, microservices. The idea: instead of one program that does everything, build many small independent programs, each owning one capability, each talking to the others over the network.

A quick vocabulary check, since these two terms get used loosely:

• Service-Oriented Architecture (SOA) — an architectural style where the system is composed of separate services that each expose a well-defined interface and communicate over the network, rather than calling each other as in-process function calls.
• Microservice — a small, independently deployable service that owns one narrow business capability (for example, "the catalog service" or "the ratings service") and its own data. Microservices are SOA taken to a fine grain.

The payoff is independence:

By the mid-2010s Netflix ran on the order of hundreds of microservices — catalog, playback, personalization, A/B testing, encoding, billing, and many more — each owned and deployed by a small team. This solved the failure and velocity problems of the monolith. But it created a brand-new problem, and that problem is what the rest of this course is about.

Here is the new problem. A Netflix client — the app on a smart TV, a phone, a game console, a browser — needs to render a home screen. That home screen pulls from many of those hundreds of microservices at once: the catalog service for titles, the personalization service for row ordering, the images service for artwork, the "continue watching" service for progress, and so on.

If every client had to know about, find, and call all those services directly, you would have chaos: every device team would have to understand the entire backend, and every backend change could break every client. So Netflix put a layer in between — an API layer, a single front door that clients call, which then fans out (splits one incoming request into many outgoing requests) to the microservices behind it and assembles the results.

An API (Application Programming Interface) is simply the contract by which one program asks another for something — the set of requests it accepts and responses it returns. The API layer is where the client's one request ("give me my home screen") becomes the many backend calls needed to build it, so that no client ever has to know the shape of the backend.

That single decision — put an API layer between clients and services — is the seed of Netflix's whole "unusual evolution." How that API layer should be designed turned out to be a surprisingly hard question, one Netflix answered three different ways over the following decade. Day 2 covers the first answer.

• A monolith — one deployable program, one datacenter, one central database — is the natural starting point but concentrates both failure risk and team friction.
• Netflix's 2008 database corruption outage was the catalyst: it exposed the single-point-of-failure danger of a central, vertically-scaled datacenter.
• Over roughly 2008–2016 Netflix migrated to AWS to gain horizontal scaling, cross-zone redundancy, and elasticity — but the cloud alone does not break a monolith.
• The real architectural change was monolith → Service-Oriented Architecture / microservices: hundreds of small, independently deployable, independently failing services, each owned by a small team.
• Hundreds of microservices created a new problem: clients cannot call them all directly, so an API layer became necessary as a single front door that fans one client request out to many services.
• The design of that API layer is the central question of this course — Netflix answered it three different ways over a decade.

• [ ] I can define monolith, SOA, and microservice and explain how they differ.
• [ ] I can explain why the 2008 outage pushed Netflix off a single central datacenter.
• [ ] I can name the three things the cloud gave Netflix that its own datacenter could not (horizontal scaling, redundancy, elasticity).
• [ ] I can explain why microservices solved the monolith's failure/velocity problems but created a new one.
• [ ] I can describe what an API layer is and why "fan-out" makes it necessary in front of hundreds of services.
• [ ] I understand that how to design that API layer is the open question the rest of the course explores.