How Large Should a Microfrontend Be?

The word “microfrontend” suggests a simple idea: a microfrontend is an especially small frontend.

That quickly leads to rules claiming that a remote should contain only a few components, represent exactly one route, or cover no more than a small area of the interface. Sometimes its size is measured by files, features, bundle size, or lines of code.

These values may matter for performance, build times, or maintainability. They do not answer the strategic question of whether an area has a meaningful boundary and can be owned independently.

A small bundle can be poorly aligned with the domain. A large remote can still have a clear and durable boundary.

The direct answer to the question of the right size is therefore: it depends—but not on lines of code, components, routes, or screen real estate.

A microfrontend should be as large as the domain-aligned scope of change that a team can reasonably and largely own independently.

“Micro” Is Not a Technical Unit of Measurement

With microservices, people quickly began asking how many lines of code or endpoints a service should be allowed to contain. The same discussion now repeats itself for microfrontends, only with components, views, and bundles.

The prefix “micro” sounds like a size specification even though it provides no meaningful unit of measurement. There is no number beyond which a frontend becomes too large to be a microfrontend. Nor does a technical unit become a useful domain boundary merely because it is small.

A remote with five components can contain several unrelated responsibilities. A remote with one hundred components can represent one coherent product area.

Visible size is hardly more useful. A small dashboard card may represent an independent domain area with its own data, release cycle, and clear responsibility. A full page, by contrast, may be only one step in a larger domain process.

The size of a microfrontend therefore cannot be inferred from its surface area. What matters is which responsibility is contained within its boundary.

A Domain-Aligned Scope of Change Instead of Screen Real Estate

A durable boundary contains capabilities that belong together in the domain. They use the same language, change for similar reasons, and can be understood and owned by one team.

The central question is:

What typically changes together—and what should be able to change independently?

Capabilities are more likely to belong in the same microfrontend when they:

• use the same domain terms and rules,
• change for similar domain reasons,
• share a manageable backend contract,
• have comparable release and change cycles,
• can be understood and owned by the same team,
• form a recognizable boundary toward neighboring areas.

Domain proximity matters more than spatial proximity.

Two elements may appear directly next to each other on the same page and still belong to different areas of responsibility. Conversely, one coherent domain area may span several pages, dialogs, routes, and background processes.

The layout of a screen describes how the interface is composed. It does not automatically describe the domain architecture behind it.

A Deep Domain Can Be Large

At first glance, a calendar for a medical practice may look like a single feature. In reality, it can contain substantial domain depth.

The calendar domain may include:

• appointment scheduling and rescheduling,
• practitioners, rooms, and other resources,
• different appointment types,
• recurring appointments and recurrence rules,
• blocked periods and absences,
• conflict detection,
• waiting lists,
• cancellations,
• permissions,
• different calendar views,
• domain rules for availability and capacity.

Such a calendar is neither technically nor functionally small. It can still form a clear domain area.

Its responsibility can be distinguished clearly from the patient record, billing, documentation, user administration, or communication. Within the calendar, many rules interact. Outside its boundary, different concepts, reasons for change, and often different responsibilities apply.

The calendar is therefore not too large simply because it is deep.

Its boundary would become problematic only if the same remote also took on independently changing areas such as billing, patient administration, and documentation. In that case, not only the domain depth increases. More importantly, the breadth of responsibility grows.

Microfrontends do not necessarily limit the depth of a domain. They primarily limit the breadth of responsibility and coordination.

A deep domain may be large as long as its outer boundary remains understandable.

When Remotes Become Too Small

A calendar page can easily be divided into several remotes from a technical perspective:

Calendar Page
├── Toolbar Remote
├── Filter Remote
├── Calendar Remote
├── Details Remote
└── Actions Remote

On an architecture diagram, this decomposition may look clean and modular. In use, however, the toolbar, filters, calendar, details, and actions may form one single domain workflow.

Changing a filter affects the calendar. Selecting an appointment opens the details. An action changes the appointment and must then update the calendar, detail view, and feedback shown to the user. Errors, loading states, and permissions affect several parts at once.

The technical decomposition does not create independent scopes of change. It merely distributes one coherent workflow across several artifacts.

Common consequences include:

• additional runtime dependencies,
• distributed state and complex synchronization,
• fragmented error and loading-state handling,
• unclear responsibility for the overall workflow,
• more complicated integration and end-to-end tests,
• slower local development,
• more build and deployment pipelines,
• shared releases despite separate deployments,
• additional observability and debugging effort.

A separately deployable widget is not yet an independently ownable product area.

This does not mean that small remotes are inherently wrong. A small area can have an excellent boundary when it represents an independent domain capability, has a clear owner, and can change independently.

A reporting widget, for example, may have its own data source, release cycle, and clearly separated responsibility. Its small visible size neither proves nor disproves its independence.

The problem is not that it is small. The problem is that it lacks domain independence.

Technical separability is not the same as domain autonomy.

When Remotes Become Too Large

The opposite of fragmentation is a remote that contains almost the entire application:

Administration Remote
├── Patients
├── Calendar
├── Billing
├── Documents
├── Users
└── Settings

Formally, this system may still be built and deployed separately. It may even have a clear technical boundary toward the host.

Inside the remote, however, several domain areas have been combined even though they could change independently. They use different domain languages, consume different backend contracts, and may be owned by different teams.

Builds and tests become broad again. Releases affect several areas. Refactorings have a large blast radius. Teams work in the same code area and must coordinate their changes.

A separate deployment pipeline does little to change that. The remote has become a frontend monolith inside the host.

A remote is not appropriately bounded merely because it can be deployed separately.

Here too, the main problem is not its number of files. What matters is that several independently changing domain areas have been bundled under one shared responsibility.

A large remote is therefore not automatically wrong. A deep domain area may be substantial. The boundary becomes suspicious when different owners, domain languages, release cadences, or security requirements meet inside the same remote.

A Route Is Not a Domain Boundary

Routes are a navigation concept. They make content addressable and determine which interface appears for a given URL.

They do not define domain responsibility.

A microfrontend may contain several routes. A route may represent only one step in a larger domain workflow. A page may integrate several independent areas. A dialog, card, or widget is not automatically a meaningful architecture boundary either.

The URL structure describes navigation. It does not automatically describe domain responsibility.

A shared layout does not create a domain relationship either. A header, navigation, and content area may look like one visual unit even though they have different lifecycles and responsibilities.

Conversely, one coherent area may be spread across lists, detail pages, wizards, and dialogs. Splitting it along those visible elements would not make its domain clearer.

A route is not a Bounded Context. A UI component is not an organizational unit.

One Remote per View Is a Heuristic

The rule “one remote per view” can still be useful. It limits the number of runtime integrations within one domain workflow and keeps state boundaries easier to understand.

A view that is largely owned by one remote is often easier to develop and test locally. Loading states, failures, and user interactions remain within one area. The host has fewer parts to coordinate.

That makes the rule a useful warning sign against excessive fragmentation.

It is not a definition of a microfrontend.

A page can certainly integrate several independent areas. Examples include navigation and other platform capabilities, an independent reporting widget, or an additional feature with its own lifecycle.

A view with many remotes becomes problematic mainly when all parts jointly form one domain workflow. Warning signs include constant state exchange, tests that only work with all remotes together, synchronized releases, and no clear responsibility for the overall experience.

One remote per view is a useful warning sign against fragmentation, but not a universal architecture rule.

Size Is Also an Organizational Question

An area can be well aligned with the domain and still be too large for one team.

The domain may be very deep, require substantial specialist knowledge, or change frequently. Several parallel initiatives, operational responsibility, and complex domain rules can increase cognitive load.

This creates an important distinction:

A boundary can be correct in the domain and still be too broad organizationally.

The answer is not automatically to distribute components or screen areas across several teams. First, examine whether the area actually contains further independent scopes of change.

The domain may contain subareas with their own language, rules, and release cadence. In that case, another split may be reasonable.

But the parts may also interact so closely that a technical split would create only more communication. In that case, the real problem may be team size, prioritization, knowledge distribution, or technical complexity rather than the domain boundary.

Several teams working inside one remote are a warning sign. They are not proof that the boundary is wrong.

Questions for a Plausible Boundary

There is no fixed formula for size. Concrete questions can still help evaluate a boundary:

• Do the capabilities use the same domain language?
• Do they usually change for the same reasons?
• Can one team reasonably understand and own them?
• Do they share a manageable backend contract?
• Are they normally released together or independently?
• Does a change regularly require coordination with other remotes?
• Would another split create genuine autonomy or only more communication?
• Does the remote contain areas with different owners?
• Do individual parts have clearly different release cadences?
• Can the area be developed and tested locally without starting large parts of the overall system?
• Is the boundary understandable in domain terms without pointing at the architecture diagram?

These questions do not produce a score or a mathematically correct size. They merely reveal whether the technical boundaries match the actual scopes of change.

The Economically Sensible Boundary Is Rarely the Smallest Technical One

Every additional remote boundary creates cost.

Remotes that are too small require additional pipelines, integration mechanisms, contracts, tests, and observability. Failures may span several runtime boundaries. Local development and troubleshooting become more difficult. Teams must coordinate even though the architecture was supposed to create autonomy.

Remotes that are too large create different costs. Builds and tests become broader. Release cycles become longer. Refactorings affect more functionality. Several teams must coordinate changes in the same area. Responsibility becomes more diffuse and decisions become slower.

The economically sensible boundary is therefore not the smallest unit that can technically be separated.

It lies where further separation creates more independent changeability than integration and operational overhead.

Boundaries Are Tested by Change

Even a carefully chosen boundary may later turn out to be wrong. Products evolve, responsibilities shift, and capabilities that were once tightly coupled develop different lifecycles.

Drawing boundaries therefore remains an architecture decision under uncertainty.

Frequent changes spanning several remotes may indicate that one coherent area has been fragmented too aggressively. Regular conflicts between several teams inside the same remote may instead suggest that the responsibility is too broad.

These signals are not automatic proof. Shared deployments alone do not make a boundary wrong. A large remote alone is not yet a frontend monolith. What matters is the coupling observed through real changes.

Good boundaries are not created by measuring once. They are tested through actual change.

The right size of a microfrontend cannot be counted. It becomes visible when a team can make changes within that boundary without regularly coordinating the rest of the product.

As small as possible is not an architecture rule. As clearly bounded as necessary is.