Arquitecturas híbridas

Estas arquitecturas combinan elementos de las categorías anteriores o introducen capas intermedias para resolver problemas específicos. Son muy comunes en sistemas reales, donde pocas soluciones encajan en una única categoría pura.

Monolito backend + Frontend desacoplado

El backend es un monolito clásico que expone una API REST. El frontend vive en un repositorio separado y se comunica exclusivamente con esa API. Es una de las arquitecturas más habituales hoy en día.

Esta arquitectura es lo que se conoce también como API-first: el backend no sabe ni le importa cómo se va a consumir su API, y cualquier cliente (web, móvil, terceros) puede usarla.

Ventajas

• Separación clara de responsabilidades entre frontend y backend.
• Equipos independientes con tecnologías distintas.
• El mismo backend puede servir a múltiples tipos de cliente.
• Sencilla de entender y operar.

Desventajas

• El monolito backend puede convertirse en un cuello de botella si crece mucho.
• CORS, autenticación y versionado de API requieren atención.

Ideal para la gran mayoría de proyectos medianos: startups en crecimiento, productos con un equipo frontend y un equipo backend diferenciados.

BFF (Backend For Frontend)

Cuando hay múltiples clientes con necesidades distintas (web, app móvil, smart TV), en lugar de una API genérica se crea una capa intermedia específica para cada cliente. Cada BFF agrega, transforma y adapta los datos del backend al formato exacto que necesita su cliente.

Ventajas

• Cada cliente recibe exactamente los datos que necesita, sin over-fetching ni under-fetching.
• Los cambios en un cliente no afectan a los demás.
• Mejora el rendimiento al reducir el número de llamadas desde el cliente.

Desventajas

• Más código a mantener: un BFF por tipo de cliente.
• Puede haber duplicación de lógica entre BFFs si no se gestiona bien.
• Añade una capa más a la arquitectura.

Ideal para productos con múltiples tipos de cliente con necesidades muy distintas.

Headless Architecture

El backend actúa como un proveedor de contenidos o servicios sin ningún conocimiento de la capa de presentación. Cualquier cliente puede consumirlo. Es el principio detrás de los CMS headless (Contentful, Strapi, Sanity) y de los e-commerce headless (Shopify Headless, Medusa).

Ventajas

• Máxima flexibilidad en el frontend: cualquier tecnología puede consumir el core.
• El mismo contenido o catálogo se distribuye por todos los canales.
• Independencia total entre capas.

Desventajas

• Requiere construir y mantener el frontend desde cero (no hay temas ni plantillas integradas).
• Mayor coste inicial de desarrollo.

Ideal para marcas omnicanal, e-commerce con presencia en múltiples plataformas, proyectos con requisitos de frontend muy específicos.

Combinaciones habituales en sistemas reales

En la práctica, los sistemas reales mezclan patrones. Algunos ejemplos comunes:

• Microservicios en backend + BFF + SPA en frontend.
• Monolito modular + SSR (Next.js) + Serverless para tareas async.
• JAMstack + CMS Headless + Serverless Functions.
• Event-Driven + CQRS en el core + API REST pública + BFF por cliente.

Ejemplo: plataforma e-commerce madura

Este sistema combina: microservicios en el backend, BFF por tipo de cliente, SSR en el frontend web, y event-driven para comunicación asíncrona entre servicios.

Cuándo aplicar cada patrón híbrido

Situación	Patrón recomendado
Backend único, varios equipos de frontend	BFF
Contenido distribuido en múltiples canales	Headless
API ya existe, se añade frontend nuevo	Monolito backend + Frontend desacoplado
Alta complejidad + múltiples clientes	Microservicios + BFF + SSR/SPA
Poco presupuesto de servidor, contenido semi-estático	JAMstack + Serverless Functions