"Should we do microservices?" is the wrong first question. The right one is: where do we actually need independent deployability? Most teams get further with a well-structured modular monolith.
What a Modular Monolith Buys You
One deployable, many well-bounded modules. You get clear internal boundaries without the operational tax of a distributed system.
app/
billing/ → owns invoices, payments
catalog/ → owns products, pricing
identity/ → owns users, sessions
shared/ → cross-cutting primitives onlyWhen Microservices Earn Their Keep
- Independent scaling of a hot path (e.g. search, media processing).
- Teams that must deploy on their own cadence.
- Strong isolation requirements for compliance or blast radius.
The hidden cost
Every network call is a new failure mode. Distributed transactions, versioned contracts, and observability across services are not free.
A Migration Path That Works
Start modular. Enforce boundaries in code. When a module genuinely needs independence, extract it using the Strangler Fig pattern — route traffic gradually, never big-bang.
Key Takeaways
Choose the architecture that matches your organizational constraints, not the one that looks impressive on a diagram. A clean monolith you can extract from beats a distributed ball of mud.