Embracing Microservices
summary
Claims six recurring anti-patterns and gives concrete fixes: a six‑person team that builds 60 services for one customer as an example of size obsession; Netflix’s thousands of services evolve only after massive scale; prefer a Majestic monolith with a few outpost apps; avoid monorepos and technology zookeepers; prefer synchronous defaults and use transactional outbox / CDC to emit events to Kafka from Postgres; favor modular monolith first, split when merge conflicts and team pain justify it.
AI-written summary · about
chapters (14)
- 0:00Introduction to microservices
- 4:32Size obsession in microservices
- 10:19Original value of microservices
- 13:52Modular monolith as a middle ground
- 17:25Evolutionary splitting of services
- 19:30Old habits in microservices
- 23:43Testing challenges in distributed systems
- 26:54Monorepos vs. per-service repos
- 29:00Embracing eventual consistency
- 32:16Synchronous vs. asynchronous communication
- 37:59Technology zoo in microservices
- 40:28DRY abuse and common libraries
- 45:19When to start with microservices
- 46:27Summary and key takeaways
