Modular Monolith vs. Microservices: How to Decide

The distributed monolith trap

One common failure mode is splitting into services before you have clear domain boundaries and team ownership. You end up with shared data, release schedules that still have to coordinate, and features that routinely require coordinated changes. The architecture looks distributed, but the work isn't independent.

And once that happens, the interactions come with extra failure modes: network latency, timeouts, retries, partial outages, and the risk that one service is running a different version of a contract than another. A local function call becomes an operational dependency - without actually reducing coupling.

So when someone says, "We need microservices because the monolith is hard to maintain," that's not a diagnosis. The underlying issues might be tangled modules, unclear ownership, slow tests, or weak deployment practices. Moving those problems across the network usually makes them more expensive to fix.

Ask what changes need to become independent

Start with concrete friction. For example:

• Do two teams repeatedly block each other's releases?
• Does one workload need far more capacity than the rest of the application?
• Can a failure in a specific function take down unrelated user journeys?
• Are security, regulatory, or data-residency requirements pushing you toward a stronger boundary?
• Do you genuinely need a separate runtime or language?

If none of those problems is happening - or you can't show it with real data - then you probably don't need services yet. A modular monolith lets you build and test boundaries without taking on the full cost of distributed operations.

What you gain from service boundaries

A service can deploy without releasing the rest of the application, as long as its API or event contracts remain compatible. It can also scale independently. If a data-processing workload needs dozens of instances while most of the product needs only a few, separating that workload may help you avoid scaling everything together.

Services can also improve failure isolation. If a bulk import process can fail or queue work, it shouldn't exhaust resources needed for checkout. A separate deployment boundary can make that isolation easier to enforce - but you still need the boring fundamentals: timeouts, queues, limits, and sane fallback behavior.

Finally, a service boundary can line up with real security or compliance needs. A system handling regulated data may require separate access controls, audit trails, or deployment ownership. The architecture should match the requirement, not assume that "separate services" automatically equal "compliant."

What the architecture costs

The cost of distributed systems isn't just infrastructure. It includes the engineering effort needed to keep the system understandable and reliable:

• Network behavior: Calls can be slow, fail, or arrive after timeouts. You need retry, timeout, and idempotency rules.
• Data consistency: A single database transaction across modules gets harder once data is owned by separate services. You may need eventual consistency, compensating actions, or a saga.
• Observability: Logs and metrics have to help you follow a request across service boundaries. Without correlated logs and distributed tracing, debugging becomes a multi-system scavenger hunt.
• Deployment and configuration: Each service typically needs its own pipeline, secrets handling, configuration, health checks, alerts, and release process.
• Contract management: Teams must keep APIs and events compatible as services evolve. Versioning is a coordination mechanism, not a substitute for good ownership.
• Cognitive load: Developers need to understand more repositories, runtime behavior, dependencies, and failure paths before making changes.

These costs aren't reasons to avoid microservices. They're the price of admission. The practical question is whether the service creates enough independent value to pay that price over time.

Compare operating costs, not just cloud bills

A service might use fewer compute resources and still cost more overall to operate. Factor in time spent on infrastructure, on-call response, deployment failures, cross-team coordination, and keeping compatibility intact. Those don't always show up clearly on a cloud invoice.

A good test is to describe the expected benefit in measurable terms. "Payments deploy independently and reduce release coordination from several days to a same-day change" is testable. "The architecture will scale better" isn't - unless you define the load, bottleneck, or service-level target you mean.

Organize modules around business responsibilities

Group code by business capability or domain context - Billing, Inventory, Users, Shipping. The exact structure depends on your product. The point isn't to create a module for every noun in the database; it's to make ownership and responsibility visible.

Inside each module, separate the public contract from private implementation. Other modules should call the contract, not reach into internal classes or rely on implementation details. That gives you room to change internals without forcing unrelated code to move.

A simplified Laravel structure might look like this:

app/
└── Modules/
├── Billing/
│   ├── Contracts/
│   ├── Internal/
│   └── Events/
└── Shipping/
├── Contracts/
├── Internal/
└── Events/

The directory names aren't the architecture. The rules are. If code in Billing can freely reach into Shipping/Internal, your boundary is only "on paper."

Protect data ownership

Avoid cross-module table access. If Billing needs shipping information, it should request it through the defined contract or respond to an event - not join directly against Shipping's tables.

It might feel faster at first. Direct table access is easy when one developer is making a change. But it creates hidden dependencies: the owner of a table can't safely change its structure because other modules might rely on undocumented assumptions. Doing that once can be manageable. Doing it across dozens of workflows makes later extraction much harder.

Internal events help reduce direct dependencies. When a module records a meaningful change, it can publish an event and let interested modules react. Use events when asynchronous or decoupled behavior fits. Don't turn every method call into an event just to make the design look "distributed."

Enforce boundaries in the build

Relying on developers to remember architecture rules doesn't scale. Add automated checks so boundary violations fail in CI - like a failing test.

In a Laravel project using Pest architecture testing, a rule could look like this:

arch('Billing does not use Shipping internals')
->expect('App\\Modules\\Billing')
->not->toUse('App\\Modules\\Shipping\\Internal');
arch('Shipping does not use Billing internals')
->expect('App\\Modules\\Shipping')
->not->toUse('App\\Modules\\Billing\\Internal');

Exact syntax varies by tools and namespace conventions. The principle is what matters: make allowed dependencies explicit and verify them continuously. Tools like Deptrac can help define and check architectural layers too.

If you don't check boundaries, they quietly become optional. Once code crosses a boundary, the "small shortcut" spreads because it makes the next change easier - until the accumulated coupling makes everything harder.

Use a decision checklist

Ask these questions before extracting a module:

That last question is worth extra attention. A wrong boundary inside a monolith can often be corrected with a refactor. A wrong boundary between services can force API changes, data migration, event redesign, and coordinated rollout. The more distributed you get, the more expensive mistakes become.

Measure friction before treating it as a reason

Look for operational evidence that actually justifies independence. Depending on the situation, that might include:

• How often one team's release is blocked by another team.
• How long a typical change takes from ready-to-merge to production.
• Which workload drives resource use, and whether it has a distinct pattern.
• Whether incidents in one capability affect unrelated parts of the product.
• How often deployments fail because teams need incompatible changes.

You don't need a months-long architecture study. A few weeks of release data and incident notes can show whether the problem is persistent or just a recent exception. Don't extract a service just to "solve" a problem that clearer ownership, better tests, or improved deployment practices would fix more directly.

Extract gradually, not through a rewrite

The safest path is incremental:

1. Start with modules and explicit contracts. Keep internal dependencies controlled and data ownership clear.
2. Measure where the architecture causes friction. Look for repeated release blocking, scaling pressure, failure coupling, or compliance constraints.
3. Choose a stable boundary. Confirm the module has coherent responsibility and other parts of the system interact through its contract.
4. Move the implementation behind a service boundary. Keep the existing contract as an API or event interface, and plan for network behavior and data ownership explicitly.
5. Route traffic progressively. Use a gradual migration approach, often called the strangler pattern, rather than replacing the whole app at once.
6. Verify the result. Make sure the original pain actually improves enough to justify the new operational surface area.

This keeps the option to extract without paying the full cost upfront. It also forces domain boundaries to emerge from real product work, not only from predictions made on a whiteboard.

Avoid the common failure modes

A few patterns regularly undermine service extraction:

• Shared databases between supposedly independent services: ownership stays coupled, and schema changes remain coordination events.
• Nanoservices: splitting too finely can create more contracts and deployments than the independence is worth.
• Extraction before domain understanding: when the boundary is still fuzzy, moving it into services makes uncertainty harder to resolve.
• Ignoring team structure: if ownership and architecture boundaries don't match, coordination friction tends to come back in a new form.
• Adding infrastructure without operational maturity: services require deployment automation, monitoring, incident response, and clear ownership. If those aren't in place, the architecture can overwhelm the team.

A service isn't independent just because it has its own repository or container. Independence shows up when you can change, deploy, operate, and scale it without routinely coordinating with the rest of the system.