Summary
Most midsize companies are making terrible architecture decisions because they're copying Netflix instead of solving their actual problems. This episode cuts through the hype and gives you a practical framework for deciding when you need microservices, when you don't, and everything in between. We talk about why "microservices" is a terrible name that encourages bad decisions, the five factors that should actually drive your architecture choices, and the spectrum of options between monolith and distributed systems that nobody tells you about. Plus, specific signals that tell you when it's actually time to evolve.
In This Episode:
- Why a 12-person team with 47 services is a disaster waiting to happen, and what they did to fix it.
- The naming problem with "microservices" and how chasing "micro" destroys your ability to ship.
- Why that address CRUD service with its own database and deployment pipeline is architectural malpractice.
- The distributed transaction nightmare: how turning a 50-line function into seven networked service calls creates a distributed systems PhD thesis.
- The five-factor framework: team size and structure, deployment frequency and blast radius, data ownership and consistency, independent scalability needs, and technology heterogeneity.
- Conway's Law isn't a suggestion, it's gravity: why your architecture will mirror your org chart whether you want it to or not.
- The rule of thumb for team size: 1-5 engineers means monolith, 5-15 means modular monolith, 15-30 means a few services, 30+ means you can start thinking about real service-oriented architecture.
- Why deploying all 12 services together with the same version number means you have a monolith with extra steps.
- The data partitioning trap: when placing an order requires coordinating across seven services, you've created distributed transaction hell.
- Why "we want to scale differently" usually isn't a good reason to split services, but video transcoding versus API serving actually is.
- The polyglot tax: every additional technology stack means different tools, longer onboarding, harder on-call, and ongoing costs forever.
- The modular monolith: the sweet spot for most midsize teams with strong internal boundaries but simple deployment.
- How to use tools like ArchUnit and dependency-cruiser to enforce module boundaries and make your CI fail when someone violates them.
- The Majestic Monolith plus strategic services pattern: keep the core together, extract two to five services for specific reasons only.
- Self-contained systems: why thinking in complete vertical slices (Customer Portal, Checkout System) beats thinking in technical services (User Service, Order Service).
- The four breaking points that signal it's time to evolve: deploy coordination hell, team bottlenecks, scaling waste, and blast radius pain.
- Why "the code is messy" is a refactoring problem, not an architecture problem, and Shopify ran on a monolith to billions in GMV.
- The hardest lesson: complexity is easy to add, simplicity is hard to maintain.