Microservices solved an org problem, then became a default
Independent deployability helps when many teams ship to the same product every day. For a 6–15 person engineering group, that independence is often theoretical — and the distributed failure modes are not.
In 2024 we see more teams extract a service only after a module has a clear owner, a clear scale bottleneck, or a different runtime need (for example, a Python inference worker next to a Node API).
What a modular monolith actually looks like
One deployable, many modules, enforced boundaries. Billing does not import the internals of catalog. Shared kernel stays small. Database schemas can still be split later because tables were never a junk drawer.
This is not a “big ball of mud with folders”. It needs lint rules, code owners, and a willingness to say no to convenience imports.
- Module APIs instead of reaching into another team’s tables.
- Synchronous calls in-process; async events only where you already need them.
- A single observability story until traffic forces a split.
When microservices are still the right call
Compliance isolation, wildly different scaling curves, or an acquisition that must stay in its own repo. Also: a background pipeline that would take the monolith down if it ran in the web process.
Do not split because a blog post promised “scale”. Split because a metric or a team contract demands it.
A default we use on new SaaS builds
Start modular monolith, design module boundaries as if they could become services, and keep the exit ramps (events, explicit APIs) cheap. That is how you get speed now without painting the architecture into a corner.
This is the same approach we take on custom SaaS and internal tools in our product engineering work.
Build this with Furiq
See our Product engineering services or start a scoped conversation with the Chennai team.
Talk to us