When to Use Microservices
Microservices solve organizational and scaling problems, not correctness problems; a well-designed monolith and a well-designed microservices system can both be correct, performant, and maintainable. The decision to adopt microservices should be driven by specific, observable pain: multiple teams blocked on each other's release trains, one subsystem needing to scale 100x while others stay flat, or a need to use different technology stacks for different subsystems (a recommendation-service in Python for its ML libraries versus a checkout-service in Go for latency).
Cricket analogy: A franchise doesn't restructure its entire backroom staff just because one player is in poor form; it only reorganizes coaching roles when there's a clear, recurring bottleneck, like the bowling coach being overloaded across three formats.
Signals That Favor Microservices
Strong signals include: more than roughly 3-4 teams regularly stepping on each other's code in the same repository, a specific subsystem (like search or recommendations) needing radically different scaling characteristics or a different technology stack than the rest of the app, and a genuine need for independent deployment cadence, for example a payments module that must pass strict compliance review on every release while the marketing-facing content module ships daily. A useful practical test: if you can name the specific team, the specific bottleneck, and the specific service boundary, you likely have a real case; if the justification is 'microservices are the modern way to build software,' you probably don't.
Cricket analogy: A board considers splitting a combined selection panel into format-specific panels (Test, ODI, T20) only once selectors are visibly overwhelmed juggling three different squads' needs at once, a concrete, nameable bottleneck.
Signals That Favor Staying Monolithic
A small team (under roughly 10-15 engineers), an early-stage product where the domain model is still changing weekly, or a system with no scaling hotspots all favor staying monolithic. Splitting too early forces the team to guess at service boundaries before the domain is well understood, and those guesses are frequently wrong, leading to costly re-splits or awkward cross-service chattiness. The industry has enough case studies, including well-known 'we split too early and had to merge back' post-mortems, to treat premature microservices adoption as a real risk, not a hypothetical one.
Cricket analogy: A young domestic team doesn't need separate specialist coaches for every discipline before it even has a settled playing eleven; get the core team right first, specialize later.
Decision checklist before splitting a monolith into microservices:
[ ] Can you name the specific team(s) blocked by shared-codebase coordination?
[ ] Can you name the specific subsystem with different scaling needs?
[ ] Is the domain model stable enough that service boundaries won't shift weekly?
[ ] Do you have (or are you building) CI/CD, observability, and API-contract
tooling per service — not just per monolith?
[ ] Have you identified which data each new service will own exclusively?
If you answered 'no' to two or more, staying monolithic (or modularizing
within the monolith first) is likely the better near-term choice.A well-modularized monolith, with clear internal module boundaries and no cross-module database access, gives most of the maintainability benefits of microservices without the network overhead. It's often the right intermediate step before a full microservices split.
- Microservices solve organizational and scaling problems, not correctness problems.
- Real signals: multiple teams blocked on a shared repo, a subsystem with distinct scaling or tech-stack needs, and independent compliance/release cadence requirements.
- A good justification names a specific team, bottleneck, and service boundary; 'it's the modern way' is not sufficient.
- Small teams, early-stage products, and systems without scaling hotspots usually favor staying monolithic.
- Splitting before the domain model stabilizes often produces wrong service boundaries that must be re-split later.
- A well-modularized monolith can capture much of microservices' maintainability benefit without network overhead.
- Treat premature microservices adoption as a documented, real industry risk, not a hypothetical one.
Practice what you learned
1. What kind of problem do microservices primarily address?
2. Which is the strongest justification for splitting out a microservice?
3. What is a documented risk of splitting into microservices too early?
4. What can give many of microservices' maintainability benefits without network overhead?
Was this page helpful?
You May Also Like
What Are Microservices?
An introduction to microservices architecture: small, independently deployable services that communicate over the network to form a larger application.
Monolith vs Microservices
A practical comparison of monolithic and microservices architectures across deployment, scaling, data management, and team structure.
Domain-Driven Design Basics
An introduction to Domain-Driven Design concepts, bounded contexts, ubiquitous language, and aggregates, and how they inform microservice boundaries.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics