You're not Netflix (Microservices, Monolith architecture)
summary
A team of five spends months building 25–30 microservices to serve five users and loses velocity; the talk shows concrete costs: eventual consistency and intermittent failures that require retries, monitoring and orchestration, and manual deployment becomes impossible as components multiply. The claim is clear: microservices buy scaling at the cost of operational complexity — dubbed the microservices premium — and the practical guidance is to start monolith for small teams or early products, then extract services as domain boundaries and team size justify it.
AI-written summary · about
chapters (11)
- 0:00Intro
- 0:52About Fuga
- 2:03Youre not Netflix
- 5:02Complex infrastructure
- 5:29Consistency
- 8:11Monolith
- 8:44Microservices
- 10:14Choosing your architecture
- 11:14Size of your team
- 11:52Stage of your product
- 12:37Domain knowledge
related talks
47mMicroservices? Monoliths? An Annoying Discussion!
19mMicroservices vs. Monolith for Scalability and Efficiency
57mEmbracing Microservices
50mMicroservices for Mortals
55mMicroservices, Where Did It All Go Wrong
26mPros/Cons of Microservices
50mEmbracing Microservices
01h 08mWhy you should never build Microservices - and why we do it anyway