Microfrontends · Resiliencia

Aislamiento de errores y resiliencia en microfrontends

Una plataforma de microfrontends tiene más piezas móviles que una sola app, así que tarde o temprano algo no va a cargar. El objetivo es que un área rota nunca tumbe todo el producto.

Por Carlos Cifuentes · Arquitecto frontend · Actualizado 2026-10-02

El aislamiento se construye

Los microfrontends suelen venderse con la promesa de que una falla en un área se queda en esa área. Eso solo se cumple si lo diseñas. Por defecto, los remotos cargados con Module Federation o Native Federation corren en el mismo documento, en el mismo hilo de JavaScript y con los mismos objetos globales. Un error sin manejar durante el arranque puede dejar al usuario con una página en blanco, igual que en un monolito.

Las formas en que falla un remoto

Falla	Causa típica	Qué ve el usuario sin protección
El remote entry no carga	Error de red, mal despliegue, caída del CDN	Área en blanco o una navegación que nunca termina
El remoto carga muy lento	Bundle grande, red lenta	Un spinner sin fin
Falta un chunk después de un despliegue	Una pestaña vieja pide archivos que se borraron	Error en la siguiente navegación
El remoto falla al arrancar	Bug, versión incompatible de una dependencia compartida	Área en blanco, a veces un shell roto
El remoto falla en ejecución	Bug en una pantalla	Pantalla congelada o a medio renderizar

Cada una necesita una defensa distinta.

Fallas de carga: capturar, reintentar, mostrar un fallback

Cargar un remoto es un import dinámico, y un import dinámico devuelve una promesa que puede rechazarse. El host debe tratar ese rechazo como un caso normal.

Captura el error donde se carga el remoto. En un host Angular suele ser la función loadChildren o loadComponent de la ruta. Agrega un catch que devuelva una ruta o un componente de respaldo.
Reintenta una vez. Muchas fallas son problemas temporales de red. Más de un reintento normalmente solo hace esperar al usuario.
Muestra un fallback útil. Indica que esa área no está disponible, ofrece un botón para reintentar y mantén la navegación funcionando. El resto del producto debe seguir usable.

El manifiesto que lista los remotos merece el mismo cuidado. Si el host lo pide al arrancar y la petición falla, no carga nada. Incluye en el host una copia de la última versión válida, o sirve el manifiesto desde el mismo origen y la misma caché que el host.

Timeouts

Un import dinámico no tiene timeout. Una petición colgada deja al usuario frente a un spinner. Envuelve la carga en una carrera contra un temporizador y muestra el fallback cuando gane el temporizador. Cuenta cada timeout como una falla de carga en tus métricas.

Chunks obsoletos después de un despliegue

Un usuario que abrió la app ayer todavía tiene referencias a los archivos de ayer. Si un despliegue los borra, la siguiente carga diferida falla. Dos hábitos lo evitan:

Conserva las versiones anteriores de cada remoto en el CDN durante un tiempo después de cada publicación. Los archivos con hash de contenido en el nombre pueden convivir.
Cuando un chunk no cargue, vuelve a pedir el manifiesto y reintenta antes de rendirte.

Errores en ejecución: una frontera por área

React tiene error boundaries. Angular no tiene un equivalente directo, así que la frontera se arma con otras piezas:

Un ErrorHandler propio en cada remoto que reporte el error con el nombre y la versión del remoto, y avise al host que esa área falló.
Un contenedor en el host alrededor de cada área montada. Cuando un área reporta un error fatal, el host reemplaza su contenido por el fallback y deja el shell intacto.
Montaje protegido. Si los remotos se montan como custom elements o con una función de montaje, envuelve la llamada en un try/catch. Un remoto que falla al arrancar nunca debe detener el arranque del host.

El shell no debe depender de ningún remoto para arrancar. Si la navegación, la sesión o el layout importan código de un remoto, una falla en ese remoto se convierte en una falla de todo. Más en el host o shell de microfrontends.

Monitoreo por remoto

No puedes arreglar lo que no puedes atribuir. Cada error y cada métrica debe llevar el nombre y la versión del remoto que lo produjo.

Etiqueta los errores con el nombre del remoto, su versión y la versión del host.
Cuenta las fallas de carga y los timeouts por remoto. Un aumento justo después de un despliegue apunta a esa publicación.
Dirige las alertas al equipo dueño. Una alerta que les llega a todos no la lee nadie.
Verifica los remote entry desde afuera. Un chequeo sintético que pide la URL de cada remote entry cada pocos minutos detecta una caída antes que los usuarios.

Rollback rápido

Cuando una publicación rompe un área, el arreglo más rápido es apuntar el manifiesto a la versión anterior. Eso solo funciona si los archivos anteriores siguen existiendo y si el manifiesto puede cambiar sin recompilar el host. Ambas son decisiones del pipeline, descritas en CI/CD para microfrontends.

Prueba los caminos de falla. Bloquea un remote entry en las herramientas de red del navegador y mira qué pasa. Si el shell sobrevive, aparece el fallback y llega una alerta al equipo correcto, tu aislamiento es real. Más en pruebas en microfrontends.

Más en esta sección

¿Planeas una migración o una plataforma de microfrontends?

En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.

Escríbeme por LinkedIn