Netflix: streaming, microservices, and billions of hours of content
Netflix is, without exaggeration, the king of microservices. The company is basically a reference point for using this architecture. But it's important to understand that Netflix wasn't always microservice-based. Like most companies, they started with a monolithic application.
A bit of history
When Netflix launched its streaming service (they used to just rent DVDs, by the way), the whole system was built as one big monolith that handled everything: user registration, the movie catalog, recommendation algorithms, and streaming.
Around 2008 there was a massive outage. The monolith collapsed under load, leaving millions of users unable to access their favorite shows. That's when the folks at Netflix decided: "We can't keep living like this." The process of moving to a microservices architecture began.
How Netflix uses microservices
Today Netflix is over 2000 microservices interacting like gears in a complex machine. Each service is responsible for a very specific job. For example:
- Recommendation service: picks shows and movies for you based on your viewing (and yes, they know you watch "Peter Rabbit" at night, so they recommended "The Polar Express").
- Streaming service: handles delivering video to your device.
- Subscription service: manages your subscriptions, notifications, and even nags you to pay for your subscription (I'm sure you've seen that).
Each microservice uses the technology that fits its function best. Streaming, for example, is optimized for high throughput, while analytics uses Hadoop and Spark.
Benefits of microservices at Netflix
- Scalability: if the whole planet suddenly decides to binge the new season of "Stranger Things", Netflix can scale just the streaming service, not the whole system.
- Resilience: if the recommendation service goes down, it doesn't stop people from watching. Late-night recommendations aren't exactly critical anyway.
- Team independence: each team at Netflix owns a specific microservice. The team owning video doesn't tango with the team working on recommendations. Nobody breaks someone else's code or blocks releases.
Traits and challenges
It's not all sunshine. Managing 2000 microservices requires solid tooling. Netflix built a whole suite of libraries and tools that many companies use today:
- Hystrix: Circuit Breaker for handling failures.
- Eureka: Service Discovery system.
- Zuul: API Gateway for routing requests.
- Ribbon: a client-side load balancing library.
By the way, many of these solutions were open-sourced by Netflix as Open Source. If you already have a project where you want to use microservices, check out their documentation on GitHub.
Uber: dynamic pricing, routing, and "everything in real time"
Uber is another giant that proved microservices work. Uber's early story is similar to Netflix: the company also started with a monolith.
A bit of history
In 2011 Uber was a small startup in San Francisco. The system was relatively simple: one app, one database. But at some point the service started scaling rapidly, and the monolith immediately showed its limitations. Managing real-time processes became especially hard, like dynamic pricing during peak demand.
How Uber uses microservices
Today Uber consists of hundreds of microservices, each covering a specific piece of functionality:
- Driver lookup service: finds nearby drivers and estimates arrival times.
- Pricing service: calculates trip cost in real time, taking into account traffic, demand, and even weather.
- Routing service: figures out the optimal route so your driver doesn't pick you up via the Arctic.
- Notification service: sends push notifications about your ride.
Each of these services runs as an independent unit and exchanges data via APIs (and by the way, Uber even has its own inter-service protocol — TChannel).
Benefits of microservices at Uber
- Tech flexibility: you can use different stacks for different microservices. For example, analytics might run Python, while maps and routing use Java.
- Real-time processing: microservices let Uber react quickly to changes, like when it suddenly starts raining and prices spike across the city.
- Scalability: the pricing service can be scaled up only during nights or holidays when demand spikes.
Traits and challenges
Uber faced major data consistency challenges. For example, if trip data is lost between microservices, drivers or riders can get upset. So Uber heavily uses Event-Driven Architecture and messaging systems to coordinate between services.
Common lessons from Netflix and Uber
From the Netflix and Uber cases it's clear that microservices aren't just a trendy thing. They let companies:
- Quickly adapt to changing conditions.
- Handle peak loads more easily.
- Organize developer teams more effectively.
But you can't ignore the challenges. Adopting microservices requires good infrastructure, reliable monitoring and logging tools. Not to mention planning the architecture carefully to avoid the "distributed monolith" anti-pattern — microservices that are still tightly coupled.
Why these examples matter to you as a developer
First, they show that even giant companies once lived with monoliths. Nobody is born a microservice architect — it's a process. Second, these case studies show that microservices are great for scalable, resilient systems, but they're not a magic wand that fixes everything.
If you're planning to use microservices in your project, remember that good design is key. Start small, don't rush to split your app into hundreds of services if there's no reason yet. And of course, learn from companies like Netflix and Uber so you don't repeat their mistakes.
GO TO FULL VERSION