Skip to content 2.0

Pros and cons of micro-frontends

Pros and cons of micro-frontends

Trying to find a problem to fit a certain pattern, set of principles or paradigm, just so we can implement it, is not the way to go about in software development. So before you decide to go with micro-frontends, you should ask yourself if you really need them. Here are some pros and cons to help you decide.

The adventure or pros


Each frontend application or component can scale independently, and also the entire application can scale out by adding more micro-frontends.

Independent deployability

Each frontend application or component can be developed and deployed independently, and may be able to fail in isolation, rendering the whole application fault-tolerant.

Team independence

Each team developing a micro-frontend can make their own architecture and tech stack decisions. This enables the team to experiment, innovate, and have their own cycles and processes.

Faster time to value

Independent deployability and teams, make it possible for them to iterate and ship faster, using the right tools to be more productive, and the technologies they’re better at.

Cost efficiency

Moving some workloads to their own deployment scheme and service, particularly when moved to the cloud, may reduce the total cost of ownership and computing, or capacity needs of the whole application.

The challenge or cons


For the implementation -including the UI definitions- to remain consistent across the whole application, particularly across the many views when that may be a requirement, and for certain conventions to be respected there should be a strong and strict governance definition that may need to be enforced to all teams.

Governance is key to ensure that the user experience is not compromised, and it’s also a guarantee of compliance with legal requirements, and other SLA’s like security, privacy, and accessibility compliance, across the whole application. This may be a challenge to implement and enforce, and may require a lot of coordination and communication between teams.


Orchestrating the deployment of decoupled components or micro-parts may require additional efforts, and even an additional piece of technology to maintain. The recommendation is to delegate this task to the same team issue governance, who will be in charge of any common framework, library, shell or monorepo, when applicable.

State management

State management is potentially the most challlenging aspect of composition, since an out of sync state can cause the application to behave erratically and even expose security or privacy flaws. Imagine a user being authenticated for some components and not for others. Or some components misinterpreting the authenticated user authorization role.

Or a banking application where the user’s balance is not being correctly sync’d across the different components.


Routing is one of the common challenges of application design, and it’s a very important aspect of both user-experience and data architecture. It is even more challenging when we’re orchestrating decoupled frontend experiences, particularly when the routes of nested components may need to be exposed to the user.

Data architecture

Together with state management, data architecture, particularly for transactional workloads, can suppose a major challenge. Imagine a gaming application that constantly saves all user scores to the database in real-time, and every sees a different score.