Microservices vs Monolith: A Pragmatic View

Few topics in software engineering generate more heated debate than microservices vs monolith. I've seen both approaches succeed and fail, and I've come to believe the debate itself is often the problem. ## The False Binary The choice isn't monolith OR microservices—it's a spectrum. The real question is: what's the right level of decomposition for your current context? ## When Monolith Wins A well-structured monolith is often the right choice when: - Team size is small (less than 10 engineers) - Domain boundaries are unclear (you're still learning the problem space) - Operational simplicity matters (one deployment, one database, simple debugging) - Time to market is critical (don't over-engineer early) The key word is well-structured. A modular monolith with clear internal boundaries gives you the flexibility to extract services later. ## When Microservices Win Microservices make sense when: - Teams need to deploy independently (Conway's Law in your favor) - Different parts need different scaling profiles - Different parts have different reliability requirements - You have clear domain boundaries (Domain-Driven Design helps here) ## The Migration Path We migrated our core platform from monolith to microservices over 18 months. What worked: 1. Strangle Fig Pattern: Route traffic to new services while the monolith still runs 2. Start with the edges: Extract services at the boundary, not the core 3. Database last: Shared database first, then gradually separate 4. Invest in platform: Service mesh, observability, CI/CD must come before the migration ## My Recommendation Start with a modular monolith. Extract services when the pain of NOT extracting exceeds the pain of extraction. And never, ever start a greenfield project with 50 microservices.