Why Micro‑Frontends Mirror Conway’s Law and When You Really Need Them

Last year I noticed many discussions about micro‑frontends in the community and wanted to write down my thoughts, but postponed it. Seeing renewed interest in a WeChat group prompted me to finally share my perspective.

1. Micro‑frontends as an embodiment of Conway’s Law in frontend architecture

Conway’s Law states that system architecture mirrors the communication structure of the organization that creates it. This principle underlies micro‑frontends (and more broadly micro‑service architecture): large organizations incur high inter‑system communication costs, which can be reduced by splitting a monolith into small, autonomous subsystems.

“Design system architecture is constrained by the communication structure of the organization that creates it.” — M. Conway

In practice, micro‑frontends focus on solving engineering problems caused by team and organizational collaboration, not merely a specific technology challenge.

2. The assumption that all large systems succumb to entropy

Large systems inevitably drift from order to disorder, turning their codebases into “mountains of mess.” If a system remains healthy, it is usually because the technology stack is updated frequently, enough engineers are involved, and product iterations are long enough.

Micro‑frontends are often adopted by “pessimistic engineers” as a defensive compromise when a system’s entropy threatens maintainability.

When you probably don’t need micro‑frontends

You (or your team) have full authority over all architectural components, meaning a single small team develops every part.

You have sufficient motivation and resources to refactor the entire system, and the benefits of direct refactoring outweigh the costs of mixing old and new subsystems.

The system and organization are inherently tightly coupled and inseparable, making the cost of splitting higher than the cost of governance.

Product experience requirements are extremely strict, tolerating zero inconsistency in UI interactions, which effectively rules out gradual, progressive upgrades.

When micro‑frontends might actually be necessary

The system needs to be both integrated into and expose integration points, typically in two cases:

Legacy systems cannot be retired while new requirements keep arriving, and simple iframe solutions are insufficient for the required UI interactions.

The system must support a dynamic plug‑in mechanism, which may eventually evolve into a micro‑frontend approach as integration complexity grows.

Components have clear service boundaries, allowing micro‑frontends to isolate complexity, prevent entropy‑driven code decay, and mitigate coordination issues caused by differing development rhythms.

In short, there is no silver bullet; architecture always involves trade‑offs, and micro‑frontends are a pragmatic tool rather than a universal solution.