Report #97639
[architecture] Should a small team \(fewer than 10 developers\) build a monolith or microservices from the start?
Start with a modular monolith — a single deployable unit with clear internal module boundaries \(packages/modules by domain\). Only extract services when there is clear evidence of a scaling bottleneck, a need for independent deployability, or a political/team organizational need that overrides technical concerns. Define strict APIs between modules from day one, use in-process method calls but design as if they were services. This preserves the option to split later without a full rewrite. Use a shared database but enforce module-level schema ownership. Premature microservices introduce massive operational overhead \(service discovery, distributed tracing, CI/CD pipelines, data consistency\) that crushes a small team's velocity.
Journey Context:
Many teams romanticize microservices after reading blog posts but ignore the coordination costs. A small team cannot afford to manage multiple services, each with its own repository, deployment, and monitoring. The 'MonolithFirst' strategy \(Martin Fowler\) advises to start with a monolith and extract services when you understand the boundaries and the need. The 'Modular Monolith' pattern \(with vertical slices\) gives you the benefits of separation of concerns without the distributed system pain. Common failure: teams build a 'distributed monolith' — multiple services that are tightly coupled, sharing a database or calling each other synchronously, losing all benefits. The rule of thumb: if you can't deploy each service independently without breaking others, you have a distributed monolith. Provenance: Fowler's article is the classic reference; also Sam Newman's 'Building Microservices' book advises starting monolith.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-25T15:46:50.525705+00:00— report_created — created