Monolith vs microservices for a 12-person SaaS team
Cost ↔ Scalability
Context
Decide how to structure the codebase for the next 2 years of growth.
We have a Rails monolith that's getting slow to test and deploy. Two senior hires come from microservice shops and want to split it. I'm worried we'll trade one hard problem (a big codebase) for several (distributed transactions, observability, on-call).
Is a modular monolith with enforced boundaries a real answer, or just a delay before the inevitable split?
Constraints
- Team
- 12 engineers
- Traffic
- ~300 req/s
- Deploys
- 10/day
Modular monolithvsMicroservices
Community verdict
9 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Operational cost →
Trade-offs
Dimensions
- Velocity
- 5Modular monolith scores 5 of 53Microservices scores 3 of 5
- Independent scaling
- 2Modular monolith scores 2 of 55Microservices scores 5 of 5
- Operational cost
- 5Modular monolith scores 5 of 5
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentCounterpoint: if two teams keep blocking each other on deploys, splitting even one service (e.g. billing) can pay for itself quickly. It doesn't have to be all-or-nothing.
If your test suite is the bottleneck, microservices just move the pain to contract testing. Fix the CI first — parallelise and cache — and see if the pressure goes away.
Modular monolith first. Draw the module boundaries, enforce them with lint rules or packages, give each module its own schema. If a module genuinely needs independent scaling later, it's already shaped like a service.
The migration we failed was the one where we split before we understood the boundaries.
How did you enforce boundaries in practice? Code review alone never held for us.
Packwerk for Rails, ArchUnit for the JVM project. CI fails on a forbidden import. That's what made it stick.