Modularity has a coordination cost

Modularity gets sold as independent change. Split the thing into clean parts, give every team a box, and everyone moves faster.

That is the pitch. The invoice arrives as coordination.

Every boundary creates a contract to design, version, test, monitor, and support. If the operating model cannot handle that work, modularity can produce more meetings and slower change than the monolith it replaced.

A boundary should remove a reason to coordinate

Separating a capability makes sense when it has a distinct owner, rate of change, scale profile, security boundary, or lifecycle.

If two components always change together, release together, fail together, and require the same people to diagnose them, they may be separate deployments without being meaningfully modular.

The architecture gained an interface. The organization gained another place to wait.

This is why service count is a bad measure of architectural maturity. More pieces can create flexibility. They can also turn an internal method call into a network, authentication, versioning, and incident-management problem.

Contracts are products

An API or event contract has consumers. It needs compatibility rules, documentation, testing, ownership, and a change process.

The provider cannot change it casually. The consumer cannot depend on undocumented behavior and then call the provider unstable. Both sides need a way to test against the same expectation.

That work is easy to underestimate because the contract looks small compared with the applications around it.

In practice, weak contracts create synchronized releases. Teams schedule changes together because nobody trusts compatibility across versions. The system is modular in the diagram and coupled in the calendar.

Team structure matters

Architecture boundaries and team boundaries do not need to match perfectly. They should at least acknowledge each other.

A team that owns only a thin technical layer may need several other teams to deliver any business outcome. A team that owns an end-to-end capability can often change implementation details without negotiating every step.

The second model creates more useful independence, but it requires broader skills and clearer product ownership.

If the organization is highly centralized around databases, integration, security, and release management, splitting the application layer into many services may not create the autonomy the program expects.

The constraint just moves to the shared teams.

Modularity changes testing

A larger number of independently deployed components increases the number of version combinations the system may experience.

Testing every combination end to end is not practical. Teams need confidence at the boundaries: contract tests, representative integration environments, production observability, and compatibility policies.

They also need to decide what happens when one component is unavailable or behind a version. Graceful degradation sounds good until nobody agrees which behavior may degrade.

Those decisions belong in the design, not the incident.

Choose the boundary with the bill attached

When evaluating a new boundary, include the recurring cost:

• contract maintenance
• deployments and environments
• identity and access
• observability
• incident ownership
• data consistency
• cross-team planning

Then compare that cost with the independence the boundary creates.

Some boundaries are absolutely worth it. A payment service, customer identity, search platform, or inventory capability may need different controls and scaling from the storefront. Other splits are just organizational discomfort translated into APIs.

Start with ownership

Before decomposing a system, ask who will own each part and what they can change without permission from everyone else.

If there is no credible answer, the architecture is probably ahead of the operating model.

Modularity is not free flexibility. We accept more explicit coordination at the boundaries to remove coordination everywhere else.

If the meetings multiplied and releases still move together, the trade did not clear.