A team of fifteen wants to start a new product as microservices. How do you advise?
Show the full answer Hide the answer
Ask what problem microservices are solving here
The pattern addresses independent deployment by independent teams, independent scaling of unlike workloads, and technology heterogeneity where it is genuinely needed.
At fifteen people on a new product, none of those apply yet. There is one team, no traffic, and no knowledge of where the boundaries actually are — which is the decisive point, because service boundaries are extremely expensive to move and, on a new product, they will be wrong.
The cost that is paid immediately
Distributed transactions, network failure between every component, distributed tracing to debug anything, an integration environment or contract testing, per-service CI and deployment, and an operational surface a team of fifteen must run alongside building the product.
That cost lands from day one; the benefit lands when there are several teams.
Recommend a modular monolith
One deployable unit with strict internal module boundaries — separate schemas per module, no cross-module database access, communication through explicit interfaces, enforced by lint rules and ownership.
It gives the code organisation, the boundary discipline and the domain clarity, with none of the distribution cost. And it makes the boundaries cheap to move while you are still learning where they belong, which is the property that matters most in year one.
The extraction path
When a module genuinely needs independent deployment or scaling — a real, evidenced need rather than an anticipated one — it extracts cleanly, because the boundary and the data separation already exist.
What to say to the team
This is not "microservices are bad". It is sequencing: earn the boundary knowledge first, pay the distribution cost when there is something to buy with it. And commit to the discipline, because a modular monolith without enforced boundaries becomes a regular monolith, which is the outcome that makes people reach for microservices in the first place.