Why Many Teams Run on Microservices but Make Decisions Like a Monolith

On paper, many systems are now "microservices".

The architecture diagram shows dozens of services, independent databases, and message queues. Teams talk about autonomy and independent deployments.

Yet day to day, decisions still feel monolithic:

• design changes require large cross-team meetings,
• releases are coordinated in big batches,
• a single database schema or API contract holds many services hostage.

The technology has changed, but the way decisions are made has not.

In this article, we look at why that happens – and what it takes to make decisions in a way that actually matches a microservices architecture.

What Microservices Promise (In Theory)

The microservices story usually promises:

• Independent deployability – teams can ship changes to their services without waiting on others.
• Local decision-making – teams can choose appropriate patterns within clear boundaries.
• Smaller blast radius – failures are contained to a subset of the system.

These benefits rely on more than just splitting code into services. They assume:

• clear ownership per service or capability,
• stable, versioned contracts between components,
• and decision-making that mostly stays within team boundaries.

When those assumptions don’t hold, the architecture behaves like a distributed monolith – and the decision process follows.

How Monolithic Decision-Making Shows Up

Even with microservices in place, several patterns pull decision-making back into monolithic shapes.

1. Central Design Committees for Everyday Choices

• Teams must present designs to a central architecture board for approval.
• Many changes, even local ones, are treated as "architecture-level".
• Decisions are batched into infrequent review slots.

This creates:

• long feedback cycles,
• a culture of "getting sign-off" instead of owning trade-offs,
• and diagrams that reflect approvals more than actual behaviour.

2. Shared Databases and Hidden Coupling

• Multiple services write to the same database tables.
• Schema changes require coordination between many teams.
• Data invariants are enforced across service boundaries.

Architecturally, this makes small changes risky. Organisationally, it:

• pulls even simple decisions into multi-team conversations,
• encourages "big bang" releases for schema changes,
• blurs ownership over data and its meaning.

3. Release Trains and Coordinated Deployments

• Releases are coordinated across many services at once.
• A shared "release window" becomes the primary control point.

This often stems from genuine concerns about risk – but it pushes behaviour back toward monolith-style decision-making:

• teams time their work to align with the train,
• rollback and recovery are planned at the whole-system level,
• experimentation becomes harder because everything moves together.

Why This Happens: Socio-Technical Gravity

These patterns are not just technical mistakes; they reflect how organisations actually work.

• Teams optimise for the boundaries they live inside.
• Risk-averse cultures centralise decisions when incidents hurt.
• Tooling and processes evolve around existing coordination habits.

If incentives, ownership, and trust are still organised like a monolith, the decision-making will be too – regardless of how the code is sliced.

Recognising this socio-technical gravity is the first step toward changing it.

Moving Decisions Closer to Services and Teams

To make decisions in a way that matches a microservices architecture, we need to:

• push more decisions into teams,
• strengthen the contracts between services,
• use central functions to set guardrails, not approve every move.

Some practical shifts:

1. Define Clear Ownership Per Service or Capability

• Every service has an owning team, with clear on-call and decision authority.
• The owning team can make most changes without cross-team approval, as long as contracts are respected.

2. Invest in Contracts and Compatibility

• Use explicit versioning for APIs and events.
• Support parallel versions during migrations instead of flag days.
• Make backward-compatibility expectations clear.

Good contracts reduce the need for monolithic coordination.

3. Use Architecture Forums for Learning, Not Approvals

• Replace many approval boards with design clinics and peer reviews.
• Focus conversations on trade-offs and patterns, not gatekeeping.

Central architecture functions then:

• share patterns,
• surface risks,
• and help resolve tensions between local and global concerns – without blocking every decision.

Aligning Microservices with Team Topologies

If microservices are meant to map to stream-aligned teams, then:

• teams should be able to own the lifecycle of the services that matter most for their streams,
• supporting platform and enabling teams should reduce cognitive load, not add new approval layers.

Misalignment shows up when:

• teams own fragments of many services with no clear end-to-end responsibility,
• platform teams become gatekeepers instead of enablers,
• org charts make service ownership ambiguous.

Aligning team scopes with service responsibilities – and vice versa – is a powerful way to make decisions feel less monolithic.

How We Look at This at Fentrex

When we review microservices architectures, we don’t just look at the code and diagrams. We also ask:

• How many teams are typically involved in a small change?
• Who can approve or reject a design decision – and how often is that needed?
• Where are databases and contracts forcing system-wide coordination?
• Do incidents and post-mortems point to architectural or organisational coupling?

We then work with teams to:

• tighten service ownership,
• improve contracts and compatibility strategies,
• and redesign decision forums to support teams, not block them.

Questions to Ask About Your Own System

If your organisation "runs on microservices" but still makes decisions like a monolith, a few questions can help:

• For a typical change in a single service, how many teams need to be involved?
• Where are we relying on shared databases or tightly coupled contracts?
• Which decisions genuinely need central alignment, and which could move closer to teams?
• Do our team structures and platform capabilities support independent decision-making, or pull us back into coordination by default?

The answers will tell you whether your architecture and your decision-making are aligned – or whether you have microservices on the diagram and a monolith in how work actually gets done.