Microservices have become a badge of engineering maturity. Conference talks describe hundreds of small services, independent teams and effortless scaling. What those talks often omit is the price: distributed systems are hard, and the teams that succeed with microservices usually have the scale, staffing and tooling to pay it. For most SaaS products in their first few years, a modular monolith gives you nearly everything you actually need with a fraction of the complexity.
What is a modular monolith?
A modular monolith is a single deployable application whose code is organised into well-defined modules that mirror business capabilities: accounts, billing, notifications, reporting, and so on. Each module owns its data and exposes a narrow, explicit interface. Other modules cannot reach into its internals or its tables directly. Calls between modules happen through those interfaces, in-process, which is fast and simple, but the boundaries are enforced by discipline and tooling as though the modules were separate services.
This differs from the "big ball of mud" monolith, where everything can call everything and the database is a shared free-for-all. A modular monolith is a deliberately structured system that is easy to reason about, test and evolve.
The hidden tax of microservices
Splitting an application into services turns simple function calls into network calls, and networks fail in ways function calls do not. You inherit a long list of new problems:
- Distributed data. A single database transaction becomes a saga of messages with compensating actions. Consistency is now something you design and test, not something you get for free.
- Operational overhead. Each service needs deployment pipelines, monitoring, logging, secrets, and on-call ownership.
- Versioning and contracts. Services must evolve without breaking each other, which requires contract tests and careful release coordination.
- Debugging. A single user action might cross ten services. Tracing tools become mandatory.
- Local development. Running a realistic environment on a laptop becomes difficult.
- Latency and failure modes. Timeouts, retries, circuit breakers and cascading failures all appear.
A team of three to fifteen developers rarely has the spare capacity to pay this tax. Every hour spent on service plumbing is an hour not spent on customer value.
What a modular monolith gives you
- Speed of delivery. One repository, one build, one deployment. A change that spans two modules is one pull request.
- Simple transactions. Cross-module operations can share a database transaction where appropriate, avoiding complex distributed patterns.
- Easy refactoring. Moving a boundary is a code change, not a cross-team migration.
- Lower cost. Fewer moving parts to host, monitor and secure.
- Easier onboarding. New developers run the whole product locally and follow code across modules.
It also scales further than most people expect. Stateless application servers behind a load balancer, a well-tuned database, caching and background workers can carry very large workloads. We describe those building blocks in our guide to architecture that survives a traffic spike.
How to structure the modules
Start by identifying business capabilities, not technical layers. Ask what the business does: manage accounts, bill customers, send notifications, produce reports. Each becomes a module. Then apply a few rules:
- Each module owns its data. Only that module reads and writes its tables. Others go through its interface.
- Interfaces are narrow and explicit. Expose use cases such as "create invoice," not raw database access.
- Dependencies point one way. Avoid cycles: if billing depends on accounts, accounts should not depend on billing. Use events to invert dependencies where needed.
- Use internal events for decoupling. When an order is placed, publish an event that notifications and analytics modules subscribe to.
- Enforce boundaries automatically. Use architecture tests or linters that fail the build when a module reaches into another's internals.
- Share as little as possible. A small shared kernel for cross-cutting concerns such as logging and authentication.
Design the database with the future in mind
Keep each module's tables in its own schema or with a clear naming prefix, and avoid foreign keys that reach into another module's tables. Where you need cross-module data, reference it by ID and fetch through the interface. This discipline costs little now and is what makes later extraction feasible: if the billing module owns its tables and talks to the rest only through an interface, moving it into a separate service is a project measured in weeks, not a rewrite measured in quarters.
When to actually extract a service
There are good reasons to split out a service, and they are specific:
- Different scaling profile. A video-processing or search component needs very different hardware and scaling from the rest of the app.
- Different reliability or security requirements. Payment handling may warrant isolation to reduce compliance scope.
- Independent team ownership. When multiple teams collide constantly in one codebase, boundaries between services can reduce friction.
- Different technology needs. A machine-learning component that requires a different runtime.
- Independent release cadence that genuinely matters to the business.
Note what is not on that list: "it feels more modern" and "it will scale better" without evidence. Measure first. If a specific module is the bottleneck, extract that module, not everything.
Migration path when the time comes
- Confirm the module has a clean interface and owns its data.
- Put an internal API in front of it, even while it is still in-process.
- Deploy it as a separate service behind the same interface, using the strangler pattern to route traffic gradually.
- Move its data to a dedicated database and remove direct access.
- Add the monitoring, tracing and deployment tooling the new service needs.
What this means for your budget and roadmap
Choosing a modular monolith is not a compromise; it is a way of deferring expensive decisions until you have evidence. It lets a small team ship faster, spend less on infrastructure, and avoid painful rewrites. It also keeps hiring simpler, since many more developers are comfortable with a well-structured monolith than with a sprawling service mesh. If your product is pre-scale, this is very likely the right foundation.
Put this into practice with CodeLuma
CodeLuma designs SaaS platforms as modular monoliths with clean internal boundaries, giving you the speed and simplicity of one deployable app and a clear path to extract services only when the business truly needs them.
- Custom software development - tailored systems, integrations and internal tools.
- Website and web application development - fast, accessible, search-friendly builds.
- Managed hosting - monitored, backed-up, Canadian-friendly hosting.
Start a conversation. Tell us about your project and we will reply with practical next steps, or browse all CodeLuma services. CodeLuma Development Inc. is based in Nova Scotia and works with teams across Canada and remotely.
