Twice a year a client arrives with the same request: "We want to rebuild our platform as microservices." When we ask why, the answer is usually a mix of scaling worry and conference talks. When we look at the system, the answer is usually a well-structured monolith away from every goal they named.
This is not a case against microservices. We run them in production for clients who genuinely need them. It is a case for matching architecture to team size, because the costs of distribution are paid in people, not servers.
What microservices actually cost
Splitting a system multiplies the moving parts. Every service needs its own deployment pipeline, monitoring, alerting, and on-call story. Every call between services swaps a function call for a network hop that can time out, retry, or arrive twice. Debugging a bug that spans three services takes distributed tracing, correlated logs, and a stronger stomach.
A team of eight engineers running 15 services spends a meaningful share of its week on the plumbing between services rather than the product. We audited one such platform in 2024: roughly 30% of engineering time went to inter-service concerns. After consolidating to 4 services, that dropped below 10% and feature throughput nearly doubled.
What a modular monolith gives you
The useful part of microservices is the boundaries, not the network. A modular monolith gives you the boundaries for free: one deployable, one database to back up, one log stream, in-process calls, and refactoring across modules with your IDE instead of a migration project.
- Organise code by business capability (billing, onboarding, scheduling), not by technical layer.
- Modules talk through explicit interfaces. No reaching into another module’s tables.
- Each module owns its schema namespace, so a future extraction has a clean seam.
- Enforce the boundaries in CI with dependency rules, because conventions decay and tooling does not.
The honest comparison
| Concern | Modular monolith | Microservices |
|---|---|---|
| Deployment | One artifact, minutes to ship | Many pipelines, orchestration required |
| Debugging | One stack trace | Distributed tracing across services |
| Data consistency | Database transactions | Sagas, outboxes, eventual consistency |
| Independent scaling | Scale the whole app | Scale hot services alone |
| Team autonomy | Shared release train | Teams deploy independently |
| Ops overhead for 10 engineers | Low | High, often a dedicated platform role |
Read the right column as a set of bills. Independent scaling and independent deployment are real benefits, but you pay for them whether or not you need them yet. Most mid-size products have one or two genuinely hot paths, and those can usually be scaled with a queue and a worker pool long before a service split is justified.
Signals that it is actually time to split
- 1Teams block each other on releases. Three or more teams queuing behind one release train, with real coordination pain, is the strongest signal.
- 2One workload has wildly different scaling needs. A document-processing pipeline that needs 40 workers at month-end while the rest of the app idles is a natural first extraction.
- 3A component needs a different runtime. A machine learning inference service in Python inside a TypeScript product justifies its own deployable.
- 4Regulatory isolation. A payment or personal-data component that auditors want fenced off can be worth extracting for the compliance boundary alone.
Notice what is not on the list: "the codebase feels big" and "we might need to scale someday." Size is solved by module discipline. Hypothetical scale is solved when it stops being hypothetical, and extraction from a well-modularised monolith typically takes weeks, not quarters.
Our default recommendation
For teams under 30 engineers: a modular monolith, a queue for async work, and one or two extracted services only where a signal above is already true. We have run this playbook across fintech, logistics, and health clients, and the pattern holds. When SummitEdge came to us convinced they needed 20 services, we shipped their compliance platform as a monolith with one extracted document service. Two years on, it handles their full audit season without drama.
If you are weighing this decision for your own platform, our custom software team does architecture reviews as a standalone engagement, and we will tell you plainly if the boring answer is the right one.