Context
A team starting a new system, or reshaping an existing one, and deciding whether to begin with microservices: splitting the system into many small services that are deployed and run separately.
The problem
Teams reach for microservices by default and start paying the price, in network calls, partial failures, and harder deployment and debugging, long before they have a reason to.
Constraints
- One thing to deploy and debug while the system is young.
- Connections to outside systems must stay isolated behind clear boundaries.
- Splitting a piece out later has to remain possible.
Approach
Start with one application, with clear boundaries between its parts. The parts that talk to outside systems sit behind connectors with a defined interface, and everything else ships as one unit. The boundaries exist so a piece can be split off later, but only when there is a real reason to.
Key engineering decisions
One deployable now
A single application avoids network calls, partial failures, and distributed debugging until they buy something.
Clear boundaries around outside systems
Outside systems sit behind connectors with a defined interface, so the boundary a future separate service would need already exists.
Split on evidence
A piece moves into its own service when there is evidence it needs to, not as a stance taken on day one.
What it demonstrates
One thing to deploy and debug now, with the option to break pieces off later: the split becomes a decision made on evidence, not a stance taken on day one.