Transición del frontend monolítico a la arquitectura multizona Next.js (Transicion Del Frontend Monolitico A La Arquitectura Multizona Nextjs)

Nota de referencia

Esta serie comparte decisiones y enfoques de diseño derivados de la experiencia de ingeniería adquirida en sistemas de producción reales. No contiene código fuente no público, datos de clientes, configuraciones de infraestructura ni información operativa interna. Los ejemplos se han generalizado o anonimizado de acuerdo con las obligaciones de confidencialidad.

Problema al principio

La interfaz monolítica no es un mal comienzo. Un solo equipo conlleva el menor costo de operaciones para un ritmo de entrega común y una superficie de producto limitada. Ingreso; Ocurre cuando las experiencias de catálogo, búsqueda, carrito, pago, cuenta y comerciante comienzan a cambiar a diferentes ritmos dentro de la misma base de código.```text Tek frontend → ortak derleme kuyruğu → ortak release penceresi → ilgisiz değişikliklerin birbirini beklemesi

İş alanları → farklı değişim ritimleri → farklı hata etkileri → farklı ölçek ihtiyaçları

## Conceptos en la primera mención```text
📦 Zone
Belirli bir URL alanından ve kullanıcı niyetinden sorumlu, bağımsız dağıtılabilen istemci uygulaması.

📦 Gateway
Tarayıcının tek bir alan adı altında gördüğü giriş katmanı; isteği doğru zone'a iletir.

📦 Independent deployment
Bir alanın değişikliğini, ilgisiz alanların release penceresine bağlamadan canlıya alma disiplini.

📦 Blast radius
Bir hata veya değişikliğin etkileyebileceği kullanıcı ve sistem alanı.
```La zona no es solo separar carpetas. También separa la propiedad, la implementación, la observabilidad y la decisión de reversión. Por tanto, el límite técnico; Debe elaborarse junto con la intención del producto y la responsabilidad del equipo.

## Problema: ¿por qué el monolito se ralentiza un día?

A medida que un mercado crece, cada área produce su propio ritmo. El equipo de búsqueda cambia el comportamiento de filtrado e indexación con frecuencia. El carrito y el pago requieren una mayor confianza y una liberación más controlada. Las herramientas de los proveedores deben poder entregarse independientemente de la experiencia del cliente. Ponerlos a todos en la misma unidad de implementación no es compartir código; la coordinación crea el compartir.```text
Katalog değişikliği ─┐
Arama deneyi       ├─ aynı build ve release kuyruğu
Ödeme düzeltmesi   ┘
```El problema no es la cantidad de archivos. El riesgo en un área de negocio determina el ritmo de entrega en otra área.

## Alternativas: opciones previas a la decisión

| Alternativa | Fuerza | Precio aceptado |
| --- | --- | --- |
| Solicitud única | Desarrollo local más simple | Lanzamiento conjunto y dominio en crecimiento |
| Federación de módulos | Compartir módulo de tiempo de ejecución | Versión, dependencia del tiempo de ejecución y costo de depuración |
| Next.js multizona | implementar de forma independiente por campo URL | Disciplina de enrutamiento, activos y contratos entre zonas |
| Dominios completamente separados | Fuerte aislamiento | Experiencia de usuario, sesión y fragmentación SEO |

La decisión de multizona no se debió a la necesidad de compartir módulos; Surge de la necesidad simultánea de cambio independiente y una única superficie de usuario. El navegador ve solo un producto. Los equipos ven áreas claras de responsabilidad del cliente.

## Decisión: asignar el límite de URL al límite de trabajos

Cada zona posee un campo URL, la intención del usuario y la responsabilidad de la versión. Gateway no es sólo un componente que dirige la solicitud correcta a la aplicación correcta; Es el límite que permite que el sistema aparezca desde el exterior como un solo producto.```text
Browser
  → Gateway
    → Catalog zone
    → Search zone
    → Cart and checkout zone
    → Account zone

Her zone
  → kendi deploy kararı
  → kendi health sinyali
  → açık route sözleşmesi
```La propiedad de la ruta debe mantenerse en un registro único. De lo contrario, dos zonas poseerán la misma URL, los comportamientos locales divergirán o las cadenas de redireccionamiento crecerán de manera invisible. Aunque el costo promedio de una búsqueda de coincidencia de URL es O(1), el costo real es la incertidumbre en el tiempo de ejecución; Por eso es necesario poner a prueba el contrato de ruta.

## Compensación: la independencia no es gratuita

Multizona; No se trata de abrir más repositorios ni mover cada página a una aplicación independiente. Cada nueva zona; Agrega construcción, implementación, verificación de estado, reversión, política de seguridad y costo de propiedad. En lugar de depender de un único almacén de clientes global, el estado entre zonas requiere contratos claros que acepten el recurso del servidor como autoridad.

Por ejemplo, es posible que desee que el contador del carrito, la renovación de la sesión o la preferencia de idioma sean visibles entre zonas. La pregunta correcta para estos datos no es en qué paquete guardarlos; quién es la fuente, cuándo se considera válida la actualización y cómo recuperarla en caso de error.

## Surgen tensiones reales en la Producción

1. **Aislamiento de activos:** Cada zona produce su propio paquete. Las direcciones de archivos estáticos y las políticas de caché deben diseñarse para que estén libres de conflictos.
2. **Enrutamiento y configuración regional:** La puerta de enlace debe reenviar la ruta dinámica y los prefijos de idioma a través de un único contrato.
3. **Sesión:** La autenticación no debería producir una experiencia fragmentada en el navegador; El comportamiento de renovación de token y cierre de sesión debe probarse en el límite de la zona.
4. **Reversión:** La implementación independiente requiere una reversión independiente. Cuando se revierte una versión de zona, se debe mantener el cumplimiento del contrato de ruta y API.
5. **Observabilidad:** si una solicitud de usuario pasa por más de una zona, las métricas en el ID de correlación, la tasa de error y el nivel de ruta deben ser visibles.

## Si rediseño hoyNo generaría zonas pequeñas antes. Primero demostraría la propiedad de la ruta, la independencia del equipo y la fricción de liberación mensurable. Mantendría los paquetes compartidos de UI, autenticación, tipos y utilidades limitados y versionables; Si el paquete compartido se convierte en un área común ilimitada por conveniencia, se produce un nuevo monolito.

El primer objetivo no es como mucho la zona; tendría el coste de coordinación más bajo.

## Frecuentemente confundido```text
❌ Multi-Zone = her sayfa için ayrı uygulama
✓ Zone, bağımsız değişen bir kullanıcı niyeti ve sahiplik sınırıdır.

❌ Multi-Zone = otomatik micro frontend başarısı
✓ Route, asset, session ve rollback sözleşmeleri bilinçli tasarlanmalıdır.

❌ Shared package = her şeyi ortaklaştırmak
✓ Shared package, stabil ve gerçekten ortak olan contract'lar içindir.

❌ Bağımsız deploy = koordinasyonsuz deploy
✓ Bağımsızlık, açık contract ve daha iyi operasyon disiplini ister.

Lista de verificación de decisiones

1. ¿La intención del usuario, el propietario y el ritmo de lanzamiento de este dominio son realmente diferentes de los demás?
2. ¿Se reduce el radio de la explosión cuando ocurre un error?
3. ¿Están claros los límites de ruta, ubicación y activos de la zona?
4. ¿Está clara la fuente de autoridad para la sesión y el estado entre zonas?
5. ¿Tiene cada zona señales de reversión, salud y observabilidad?
6. ¿Se ha anotado claramente el coste de esta decisión frente a la Federación de Módulos o al monolito modular?

Un límite incluye no sólo el tiempo de implementación; Las pruebas son valiosas si reducen los costos de incidentes y decisiones.

Lo que debes recordar de este artículo

El propósito de Multi-Zone no es fragmentar la interfaz; es limitar el efecto del cambio al límite correcto.

Monolith puede ser la elección correcta durante mucho tiempo. La descomposición sólo tiene sentido cuando se demuestran juntos la necesidad de un cambio independiente, el aislamiento de errores y la entrega controlada.

Profundizaremos en la decisión alternativa en la siguiente sección: ¿Por qué no la federación de módulos?