Context
A team starting a new system, or reshaping an existing one, and deciding whether to begin with microservices.
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.
- Integrations with outside systems must stay isolated behind clear boundaries.
- Splitting a piece out later has to remain possible.
Approach
Start with one application, with clean seams built in. The parts that talk to outside systems sit behind connectors with a clear boundary, and everything else ships as one unit. The seams 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.
Contract-shaped seams at external boundaries
Outside systems sit behind connectors with explicit contracts, so the boundary a future service would need already exists.
Split on evidence
A piece moves out of process 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.