Netflix split their application into over 700 microservices. Amazon has thousands. But many successful companies — including Basecamp and Stack Overflow — run on a single monolith and do just fine.
So which is better? The honest answer: it depends. But after reading this, you will know exactly when to choose each.
The LEGO Analogy
LEGO set vs Play-Doh
Monolith = Play-Doh. It is one big piece. Easy to shape, easy to work with when small. But when you add more and more clay, it becomes heavy, hard to manage, and if one part gets damaged, it can affect the whole thing.
Microservices = LEGO bricks. Each brick is independent. You can replace one brick without touching the others. You can build different sections of your castle with different teams. But connecting all the bricks together requires planning, and a bag full of loose LEGO bricks is harder to manage than one piece of Play-Doh.
Neither is better in all situations. The question is: which fits your project right now?
What is a Monolith?
A monolith is a single application where all the code lives and runs together. Your user authentication, product catalog, payment processing, email sending — all in the same codebase, deployed as one unit.
┌────────────────────────────────────────┐
│ MONOLITH APP │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Auth │ │ Products │ │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Payments │ │ Email │ │
│ └──────────┘ └──────────┘ │
│ │
│ One database │
│ One deployment │
└────────────────────────────────────────┘
Shopify, GitHub (for a long time), and Stack Overflow are all monoliths. They serve millions of users just fine. A monolith is not a sign of bad engineering.
What are Microservices?
Microservices split your application into many small, independent services. Each service:
- Does one specific thing well
- Has its own database
- Communicates with other services via APIs or messages
- Can be deployed independently
Microservices architecture
Each box is a separate application, running on its own server, with its own database. A team can work on the Order Service without ever touching the Product Service.
The Real Comparison
Why Netflix Moved to Microservices
Netflix started as a monolith. When their DVD-by-mail service moved to streaming, the traffic exploded. In 2008, a database corruption bug took the entire site down for 3 days.
That moment changed everything. If one bug in one part of the code can kill everything, you need isolation.
The office building analogy
A monolith is like one giant open office. A fire in the kitchen affects everyone. Microservices are like separate office buildings. A fire in building A does not spread to buildings B, C, or D. Each building has its own fire alarm, its own exits, its own management.
Netflix needed:
- The video streaming part to scale independently from the billing part
- A bug in recommendations to never affect the ability to play videos
- 50+ engineering teams to work without stepping on each other
Microservices solved all three. But it created new problems: 700 services to monitor, complex network communication, distributed system failures. There is no free lunch.
The Honest Advice
You are a startup or small team. You are still figuring out your product. You have fewer than 20 engineers. Speed of development matters most. This is what most successful companies did — including Twitter, Uber, and Airbnb.
You have 50+ engineers who keep blocking each other. Specific parts of your app have completely different scaling needs. A bug in one area genuinely threatens your whole business. You have the DevOps maturity to manage distributed systems.
Building microservices from day one because Netflix does it. Netflix has thousands of engineers. Their problems are not your problems. Starting with microservices as a 3-person startup will slow you down dramatically with zero benefit.
Summary
A monolith is one app. Simple to build, simple to deploy, simple to debug. It has a ceiling — at large scale, it becomes hard to manage.
Microservices are many apps. Independent, scalable, resilient. They have a floor — the complexity overhead is only worth it above a certain company size.
The pattern that actually works: start monolith, extract services when you feel real pain. Not theoretical pain. Real pain. That is what Netflix, Amazon, and Uber all did.
Build something that works first. Optimize the architecture when the current one becomes the bottleneck.