Arquitecturas Web - Modelos_

El diseño de la arquitectura de una aplicación web determina cómo se estructuran, comunican y despliegan sus componentes. A la hora de afrontar un despliegue, es fundamental conocer la arquitectura subyacente, ya que la infraestructura necesaria variará drásticamente.

1. Arquitectura Monolítica

• Concepto: Toda la aplicación se construye, empaqueta y despliega como una única unidad funcional. La interfaz de usuario (UI), la lógica de negocio y la capa de acceso a datos comparten el mismo código base y se ejecutan en un mismo proceso.
• Ventajas:
  • Desarrollo inicial rápido.
  • Facilidades para realizar pruebas end-to-end.
  • Despliegue muy sencillo mediante un único artefacto (por ejemplo, subir un archivo .war en Java o la carpeta de un proyecto PHP al servidor).
• Inconvenientes:
  • Escalado rígido: es necesario duplicar toda la aplicación (y consumir más recursos) aunque solo un módulo se sature.
  • Alto acoplamiento: un error en un módulo puede tumbar el sistema completo.
• Ejemplo: Un portal e-commerce tradicional desarrollado en WordPress, Prestashop, o una aplicación Laravel/Django clásica donde las plantillas HTML, la lógica backend y las consultas a la base de datos residen en el mismo servidor web.

Diagrama conceptual:

+-------------------------------------------------------+
|                Aplicación Monolítica                  |
|  [ Interfaz (UI) | Lógica Negocio | Acceso a Datos ]  |
+-------------------------------------------------------+
                           |
                    [ Base de Datos ]

Esquema visual:

2. Arquitectura Cliente/Servidor

• Concepto: Divide la aplicación en dos roles bien definidos y desacoplados. El Cliente (Frontend) asume la presentación e interacción con el usuario, mientras que el Servidor (Backend) gestiona la lógica de negocio y el almacenamiento. Se comunican a través de la red mediante protocolos estándar (HTTP/HTTPS) consumiendo APIs (REST o GraphQL).
• Ventajas:
  • Separación clara de responsabilidades (equipos de Frontend y Backend pueden trabajar en paralelo).
  • Reutilización del backend para diferentes clientes (la misma API sirve para la web y para una app móvil nativa).
  • Posibilidad de escalar la capa de servidor sin afectar a la interfaz.
• Inconvenientes:
  • Mayor latencia al depender de la red para pintar los datos.
  • Necesidad de diseñar, documentar y mantener contratos de API rigurosos.
• Ejemplo: Una Single Page Application (SPA) construida en React, Angular o Vue que se aloja estáticamente en un CDN (como Netlify o Vercel), y que realiza peticiones asíncronas a una API REST desarrollada en Node.js/Express o Spring Boot desplegada en un servidor distinto.

Diagrama conceptual:

[ Cliente (Navegador / App Móvil) ]
             |  
             |  Peticiones HTTP / JSON (API REST)
             v  
[ Servidor Web / API Backend ]
             |  
             v  
     [ Base de Datos ]

Esquema visual:

3. Arquitectura de Microservicios

• Concepto: La aplicación se descompone en una colección de servicios independientes, pequeños y orientados a una función específica del dominio (por ejemplo: usuarios, pagos, catálogo). Cada microservicio ejecuta su propio proceso, suele tener su propia base de datos dedicada y se comunica con los demás mediante APIs ligeras o gestores de colas de mensajes (como RabbitMQ o Kafka).
• Ventajas:
  • Escalabilidad muy granular: si el servicio de pagos tiene mucha carga, solo se escalan las instancias de ese servicio.
  • Alta tolerancia a fallos: si un servicio cae, el resto de la aplicación sigue funcionando (aislamiento de fallos).
  • Flexibilidad tecnológica (políglota): un microservicio puede estar en Python, otro en Java y otro en Go.
• Inconvenientes:
  • Alta complejidad en la infraestructura y el despliegue. Requiere herramientas de orquestación avanzadas.
  • Latencia en la red interna debido a la constante comunicación entre servicios.
  • Mayor dificultad para realizar pruebas de integración y mantener la consistencia de los datos distribuidos.
• Ejemplo: Plataformas enormes como Netflix, Amazon o Spotify. Por ejemplo, en una tienda online, la autenticación de usuarios, el motor de recomendaciones, el catálogo y el procesador de pagos operan como microservicios independientes desplegados autónomamente.

Diagrama conceptual:

                 [ API Gateway ]
               /        |                      v         v         v
      [Serv. Usuario] [Serv. Pago] [Serv. Catálogo]
             |              |             |
        [(DB User)]    [(DB Pago)]   [(DB Catálogo)]

Esquema visual:

Nota para despliegue: Para el despliegue moderno en producción, los entornos monolíticos suelen empaquetarse en un servidor VPS tradicional o un hosting compartido; las arquitecturas Cliente/Servidor combinan almacenamiento de archivos estáticos (S3/CDN) con instancias dedicadas a la API; y los Microservicios se despliegan de forma casi obligatoria sobre clusters de contenedores utilizando herramientas como Docker y Kubernetes.