Microfrontends a escala: lo que nadie te dice hasta que ya lo estás viviendo
Tres años desplegando una arquitectura de microfrontends en producción. Errores costosos, decisiones que salieron bien y lo que cambiaríamos hoy.
Diego Fuentes
Staff Engineer
21 Apr 2025
10 min lectura
Por qué adoptamos microfrontends
En 2022 teníamos un monolito de React con 340,000 líneas de código, cuatro equipos de frontend y tiempos de compilación que superaban los 12 minutos. La solución parecía obvia: partir el frontend en piezas independientes que cada equipo pudiera desplegar a su ritmo.
Lo que no teníamos tan claro era el costo oculto de esa decisión.
El problema del estado compartido
Cuando tienes tres microfrontends cargados en la misma página — header, sidebar y contenido principal — y los tres necesitan saber si el usuario está autenticado, tienes un problema de estado compartido. Las soluciones son pocas:
- Un
CustomEventen elwindow(funciona, pero es frágil) - Un store externo compartido via Module Federation (acoplamiento implícito)
- Mover toda la lógica de auth al shell y propagarla vía props
Optamos por la tercera y es la que menos nos ha dado problemas.
Lo que sí refactorizaríamos
La decisión que más nos ha costado: compartir la design system como un paquete npm versionado. Cada vez que actualizamos un componente base, los equipos tienen que actualizar su dependencia manualmente. Hoy usaríamos Module Federation para la design system y npm solo para utilitarios sin UI.
Los microfrontends no te dan velocidad gratis. Te dan la posibilidad de escalar la velocidad si haces el trabajo de infraestructura primero.
Métricas que importan
Después de tres años, nuestros tiempos de deploy por equipo bajaron de 45 minutos a 4. Los incidentes cruzados entre equipos bajaron un 60%. Pero el tiempo de onboarding de ingenieros nuevos subió: la arquitectura es más difícil de entender que un monolito bien documentado.