Do Microfrontends Need Microservices?

No. Microfrontends do not need microservices.

Microfrontends and microservices initially answer two different questions. One concerns how the frontend is decomposed and integrated. The other concerns how the backend is decomposed. These decisions can be aligned, but they do not have to share the same boundaries—and they certainly do not have to be introduced together.

Several microfrontends may sit in front of a traditional backend monolith. The backend may instead be a modular monolith, a landscape of shared services, a dedicated API facade for each remote, or a fully self-contained system with its own domain logic and data ownership.

A shared backend does not invalidate microfrontends. It merely determines how far their autonomy reaches.

A patient remote, a calendar remote, and a billing remote can represent distinct domain areas, be developed, built, and delivered by different teams, and even be used in different hosts. All three may still consume the same backend.

Their ability to change independently may then end at the shared backend boundary. That does not negate the value of decomposing the frontend. It simply shows that autonomy is not binary. A team may be able to change and release its remote independently while still depending on a centrally owned backend whenever the underlying domain logic must change.

That can be a deliberate and economically sensible boundary.

Two Separate Architecture Decisions

Frontend and backend topology can be viewed as two independent axes:

Frontend:
monolithic ───────────────────────── Microfrontends

Backend:
Monolith ─ Modular Monolith ─ Services ─ Self-Contained Systems

A position on one axis does not force a particular position on the other.

A monolithic frontend may consume numerous microservices. Conversely, several microfrontends may sit in front of a single backend:

Patient Remote ──┐
Calendar Remote ─┼── Shared Backend
Billing Remote  ─┘

This is still a microfrontend architecture. The frontend areas may continue to have their own codebases or code areas, build processes, release cycles, and ownership.

Not every combination enables the same scope of autonomy. A team that owns only the remote can make different decisions from a team that also owns the backend contract, the domain logic, and the associated data. But this does not create a maturity ladder that inevitably ends with microservices.

A modular monolith is not automatically an unfinished microservice architecture. A shared backend is not automatically an architectural flaw. And a system with many deployments is not automatically well decomposed.

Backend topology should be judged by which responsibilities genuinely need to be exercised independently and by how much operational cost that independence justifies.

A Backend Monolith Can Still Provide Good Boundaries

A monolith does not have to expose one global API through which every frontend area reads and changes the same models.

Domain-aligned contracts can also exist inside a backend that is built and delivered as a single unit:

Calendar Remote → Calendar API
Patient Remote  → Patient API
Billing Remote  → Billing API

All three APIs may be implemented in the same process and released together. What matters first to their consumers is whether the contracts are understandable, stable, and appropriate for the domain—not how many containers are running after deployment.

This setup is particularly plausible when frontend teams already work independently while the backend remains centrally organized. The same applies to incremental migrations. Existing applications can rarely be decomposed across every layer at once. It may be reasonable to separate frontend ownership first while continuing to use the existing backend in a controlled way.

A stable backend area that changes only rarely does not automatically justify being split into several services either. Additional deployments, network interfaces, monitoring, and failure modes are not free expressions of architectural purity. They should solve a concrete problem.

The monolith does not become problematic merely because it is delivered as one unit. It becomes problematic when it fails to provide durable boundaries: when every remote consumes the same global DTOs, adopts internal data structures directly, or depends on changes across several poorly defined domain areas for even a small feature.

What is missing in that case is not primarily another service. What is missing is a meaningful contract.

The Modular Monolith Is a Strong Option

A modular monolith can make domain boundaries in the backend more explicit without immediately taking on the operational costs of a distributed system.

Calendar Remote → Calendar Module
Patient Remote  → Patient Module
Billing Remote  → Billing Module

The modules may share one build and one deployment. They can still have different owners, their own internal models, and clearly defined interfaces.

A modular monolith therefore combines qualities that discussions about microfrontends often treat as unnecessarily opposed: domain separation and shared operation.

A calendar team can own the calendar remote, its API contract, and the corresponding backend module. It does not need its own cluster or necessarily its own database. At the same time, it does not have to coordinate every change to a global backend model with every other team.

A shared deployment does mean that changes are delivered together. It does not automatically mean that every change must be developed, decided, or owned by everyone together.

A modular monolith can also simplify transactions and consistent changes within the system. It creates fewer distributed failure modes and requires less operational infrastructure than a landscape of independently deployed services. These properties are not shortcomings that must eventually be overcome. They may be exactly what the problem requires.

Microfrontends do not necessarily need separate backend deployments. They often need separate backend responsibilities first.

The Contract Matters More Than the Number of Services

The relevant question is not:

How many backend services exist?

The more important question is:

Can the responsible team understand, evolve, and stabilize the contract of its remote without triggering an organization-wide release train for every change?

A backend monolith can provide a good contract. A microservice system can remain highly coupled despite its many deployments.

This becomes especially obvious when a remote accesses many internal services directly:

Remote
├── User Service
├── Calendar Service
├── Location Service
├── Authorization Service
└── Billing Service

On an architecture diagram, the system appears finely decomposed. For the remote, however, a single view may now have five synchronous dependencies, need to combine several failure modes, and account for the versions of multiple services.

If a new calendar view requires additional user data, location information, and authorization rules, three or four backend teams may need to become involved. The frontend team may own an independently deployed remote and still be unable to deliver the feature independently.

The integration complexity has not disappeared. It has moved into the browser.

The situation becomes even worse when the remote consumes internal backend models directly. Shared user, location, or authorization DTOs may initially look like reuse. In reality, they turn internal decisions from several services into part of the frontend contract. A domain change can then affect numerous consumers.

Microservices do not automatically protect a system from such dependencies. They may even multiply them when their internal interfaces are exposed directly as frontend APIs.

The number of services is not a reliable indicator of boundary quality.

A meaningful contract hides the internal topology wherever that topology is irrelevant to the remote. The frontend should not need to know how many services are required to compose a view. It should receive a model that fits its task and is owned by a clearly identified party.

A contract is also more than a set of endpoints and DTO schemas. It includes domain semantics, error behavior, compatibility rules, and responsibility for its evolution.

Contracts Must Remain Evolvable

A contract is not durable merely because a team name has been attached to it. What matters is how it can evolve.

A good contract has a clear owner and known consumers. It can be extended in backward-compatible ways, handles breaking changes deliberately, and does not force every participating application into a synchronized release whenever it changes.

This requires the contract not to simply mirror internal backend models. Internal structures change for different reasons than a remote’s requirements. If the two models are treated as identical, every internal refactoring can become a frontend migration.

Known consumers matter as well. A contract whose usage nobody understands can only appear to change independently. Fear of unknown impact causes old fields to remain forever, or every modification to be protected by organization-wide coordination.

Automated contract tests can make these relationships visible and detect accidental incompatibilities. They cannot replace clear ownership or a meaningful interface. More tests merely make a poor contract reliably poor.

A clearly owned contract is a durable boundary only when it can change without requiring every consumer to be updated at the same time.

Ownership Is the Real Core Problem

Architecture discussions tend to focus on visible technical boundaries: repositories, deployments, containers, databases, and API endpoints. They can be counted and drawn in diagrams.

Ownership is less visible, but usually more decisive. Domain boundaries and ownership are not alternatives to architecture; they are its strategic core.

A setup of remotes, BFFs, and microservices is of little help when nobody owns the full path of a domain change. The same is true when several teams can modify the same model, failures are passed between areas of responsibility, or a central backend team must approve and implement every change.

In such organizations, technical decomposition may even create more handovers. A single change turns into tickets for several teams even though the domain requirement belongs to only one area.

The decisive questions are therefore not merely technical:

• Who owns the contract?
• Who decides how it evolves?
• Who is accountable for failures at this boundary?
• Which other teams must approve a change?
• Where does the team’s domain responsibility end?

A modular monolith can provide very good answers:

Calendar Team
├── owns the Calendar Remote
├── owns the Calendar Contract
└── owns the Calendar Module in the shared backend

The backend is delivered as one unit. Its domain responsibility does not therefore have to be shared or ambiguous.

Conversely, a calendar microservice may be operated by a central platform team, while the calendar remote belongs to a product team and the API contract is approved by a third committee. Despite three technical deployment boundaries, nobody owns the change end to end.

Deployment boundaries can support ownership. They cannot replace it.

When a BFF Is Useful

A remote-specific Backend for Frontend (BFF) or API facade can correct an unsuitable backend boundary without requiring the entire backend to be decomposed again.

Calendar Remote
       │
       ▼
Calendar BFF
       │
       ├── Backend Monolith
       ├── User Service
       └── Location Service

The BFF can aggregate data from several sources and provide the remote with a model designed for its particular tasks. It can hide internal service boundaries, normalize errors, and shield the frontend from changes to the backend topology.

The calendar remote then does not need to know which service provides user names, where locations are managed, or how authorization is resolved internally. It consumes a contract designed for the calendar domain.

A BFF can also make responsibility more tangible. If the calendar team owns both the remote and its BFF, it can evolve the frontend contract itself even when the underlying systems still belong to other teams.

That is not automatic, however.

A thin proxy that forwards the same global DTOs unchanged does not create a domain boundary. A BFF can also synchronously couple numerous internal services, expose their failures without translation, and require several teams for every change.

A BFF is a tool for designing contracts, not a certificate of authenticity for microfrontends.

If the existing backend already offers a suitable, clearly owned contract, an additional BFF may be nothing more than another deployment without additional value.

When Microservices or Self-Contained Systems Make Sense

Microservices or complete Self-Contained Systems become interesting when the intended responsibility genuinely needs to extend further into the backend.

Remote
  │
  ▼
Own API
  │
  ▼
Own Domain Logic
  │
  ▼
Own Data Responsibility

A team can then change not only the presentation and frontend contract, but also evolve and deliver the underlying domain logic independently. It depends less on a central backend team and can partly control its own release cycle, scaling, and failure isolation.

This scope can be valuable for independently evolving domain areas. It becomes particularly plausible when backend changes are needed frequently, central teams become a permanent bottleneck, or different areas have substantially different requirements for scale and availability.

The additional autonomy comes at a price.

Every independent backend area needs build and deployment processes, runtime environments, monitoring, logging, and people responsible for its operation. Local method calls become network connections. Failures can occur partially. Data must cross system boundaries. Contracts now exist not only between frontend and backend, but also between backend areas.

A team that owns a complete vertical slice therefore gains not only more freedom. It also takes on more responsibility.

Microservices are not a prerequisite for microfrontends. They are one possible answer when the intended responsibility genuinely needs to extend into the backend and the data layer.

Dedicated Data Is Not a Prerequisite

A microfrontend does not need its own database.

Even a team with its own backend module or service may initially access jointly managed data. The relevant question is again which changes it needs to perform independently and which rules govern shared ownership.

Complete end-to-end autonomy does, however, end where several areas modify the same domain data structures without clear responsibility. A shared database is therefore not automatically a problem. Shared, unresolved ownership is.

Data ownership marks another possible boundary of autonomy. It should be separated only when the domain and organizational benefits justify the additional cost.

Choosing the Right Backend Boundary

The appropriate topology does not depend on which architecture style is considered more modern. It depends on how far a team’s independent responsibility should extend.

With UI autonomy, the team primarily owns its remote:

Remote → Shared API → Shared Backend

This may be sufficient when backend changes are rare, the existing API is stable, and shared backend releases do not create a practical obstacle.

With contract autonomy, the team also owns a dedicated API facade or BFF:

Remote → Dedicated BFF → Shared Backend

This variant can make sense when the backend does not provide a suitable frontend model or the remote would otherwise need to integrate several internal sources itself. The team can design its own contract without already taking over all domain logic and data.

With end-to-end autonomy, responsibility extends beyond the remote and the contract into the domain logic and potentially the data:

Remote → Dedicated Backend Area → Own Domain Logic → Own Data

This creates a complete vertical slice, but it also brings the highest operational and organizational cost.

None of these variants is generally superior. A broader scope of autonomy is valuable only when it is actually used. A dedicated service whose changes still depend on a central team and that is released together with every other system achieves little. A clearly owned module in a shared backend can be highly effective.

Concrete questions are therefore more useful than architecture labels:

How often does the remote require backend changes? Does a central team repeatedly become a bottleneck? Must the responsible team be able to deliver independently all the way into the domain logic? Are shared releases a problem, or are they intentionally aligned with the domain? Can a modular monolith already provide sufficient ownership? Does the remote currently have to orchestrate internal services itself? And above all: who owns the contract and its evolution?

Microfrontends do not need microservices. They need a backend boundary that does not erase their intended autonomy whenever something changes.

Not every remote needs its own backend. But every remote needs a contract whose evolution the responsible team can control.