El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

La arquitectura cliente-servidor es el modelo de comunicación distribuida más influyente de la historia del software. Desde las primeras aplicaciones de escritorio que se conectaban a una base de datos central, pasando por las arquitecturas de tres niveles, hasta la web que usas cada día: prácticamente todo lo que se comunica por red sigue, en su raíz, el patrón cliente-servidor. A diferencia de la arquitectura en capas (que organiza el código), la arquitectura cliente-servidor organiza la distribución física del sistema entre máquinas. En esta lección recorreremos los modelos de dos y tres niveles, la diferencia entre clientes ligeros (thin) y pesados (thick), y cómo todo ello evolucionó hacia la arquitectura web moderna.

Contenido

El modelo cliente-servidor
Modelo de dos niveles (2-tier)
Modelo de tres niveles (3-tier)
Thin client vs thick client
La evolución hacia la web
Ventajas e inconvenientes
Errores comunes y consejos
Ejercicios
Conclusión

El modelo cliente-servidor

En el modelo cliente-servidor, las responsabilidades se reparten entre dos roles:

Cliente: inicia las peticiones. Pide datos o servicios.
Servidor: espera peticiones, las procesa y devuelve respuestas. Centraliza recursos compartidos (datos, lógica).

sequenceDiagram
    participant C as Cliente
    participant S as Servidor
    C->>S: Petición (p. ej. "dame la póliza 42")
    S->>S: Procesa / consulta recursos
    S-->>C: Respuesta (datos de la póliza)

Características esenciales:

Asimetría de roles: el cliente pide, el servidor sirve. No son iguales (a diferencia de las redes peer-to-peer).
Centralización: el servidor concentra los recursos compartidos, lo que facilita la gestión, la seguridad y la consistencia.
Comunicación por red: cliente y servidor son tiers distintos; entre ellos hay latencia, fallos posibles y necesidad de un protocolo.

Modelo de dos niveles (2-tier)

El modelo de dos niveles fue el primero en popularizarse en los años 90 con las aplicaciones de escritorio corporativas. El reparto típico:

Tier 1 — Cliente: la aplicación de escritorio, que contiene la interfaz y la lógica de negocio.
Tier 2 — Servidor de base de datos: almacena los datos y, a menudo, parte de la lógica en stored procedures.

graph LR
    C[Cliente de escritorio\nUI + Lógica de negocio] -->|SQL por red| BD[(Servidor de Base de Datos)]

-- En 2-tier era común meter lógica de negocio en la propia BD
CREATE PROCEDURE contratar_poliza(IN cliente VARCHAR(120), IN riesgo VARCHAR(60))
BEGIN
    -- Regla de negocio embebida en el servidor de datos
    IF riesgo = 'NO_ASEGURABLE' THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Riesgo no asegurable';
    END IF;
    INSERT INTO polizas(cliente, riesgo) VALUES(cliente, riesgo);
END;

Problemas del 2-tier que motivaron su declive:

Cliente "gordo" difícil de mantener: cada cambio de lógica obligaba a reinstalar la aplicación en cada PC.
Escalabilidad limitada: cada cliente abría su propia conexión a la BD; con cientos de usuarios, la BD se saturaba.
Lógica dispersa: las reglas vivían a medias en el cliente y a medias en stored procedures, difíciles de versionar y probar.

Modelo de tres niveles (3-tier)

El modelo de tres niveles introduce un nivel intermedio —el servidor de aplicaciones— que concentra la lógica de negocio. Es el modelo dominante en aplicaciones empresariales.

Tier 1 — Presentación (cliente): navegador o cliente ligero. Solo presenta.
Tier 2 — Aplicación (servidor de aplicaciones): contiene la lógica de negocio.
Tier 3 — Datos (servidor de BD): persiste la información.

graph LR
    C[Cliente\nNavegador] -->|HTTP/JSON| A[Servidor de Aplicaciones\nLógica de negocio]
    A -->|SQL| BD[(Servidor de Base de Datos)]

Aspecto	2-tier	3-tier
Dónde vive la lógica	En el cliente y/o en la BD	En el servidor de aplicaciones
Mantenimiento del cliente	Costoso (reinstalar)	Sencillo (centralizado en el servidor)
Escalabilidad	Limitada	Buena (se escala el tier intermedio)
Conexiones a BD	Una por cliente	Compartidas (pool en el servidor)
Despliegue de cambios	En cada máquina cliente	En el servidor

No confundas los tres niveles físicos con las tres capas lógicas de la lección anterior. Coinciden a menudo (presentación/negocio/datos), pero son conceptos distintos: las capas organizan código y las niveles organizan despliegue. Un servidor de aplicaciones 3-tier puede tener internamente sus propias capas.

Thin client vs thick client

La gran pregunta del diseño cliente-servidor: ¿cuánta responsabilidad pongo en el cliente?

Thin client (cliente ligero): apenas presenta; toda la lógica está en el servidor. Ejemplo clásico: una web servida íntegramente desde el servidor, un terminal.
Thick / fat client (cliente pesado): contiene lógica significativa y estado. Ejemplo: una app de escritorio o una SPA moderna con mucha lógica en el navegador.

graph TD
    subgraph Thin Client
        T1[Cliente: solo render] --> T2[Servidor: render + lógica + datos]
    end
    subgraph Thick Client
        K1[Cliente: UI + lógica + estado] --> K2[Servidor: API + datos]
    end

Criterio	Thin client	Thick client
Lógica en el cliente	Mínima	Significativa
Funcionamiento offline	No	Posible
Despliegue de cambios	Inmediato (todo en servidor)	Requiere actualizar el cliente
Carga en el servidor	Alta	Menor (parte se delega)
Latencia percibida	Depende del round-trip	Buena (reacciona en local)
Seguridad de la lógica	Alta (oculta en servidor)	Menor (el código viaja al cliente)

// Ejemplo de thick client (SPA): el cliente valida y guarda estado localmente
function validarPrima(prima) {
  // Lógica ejecutada en el navegador (thick): respuesta inmediata sin red
  if (prima <= 0) return "La prima debe ser positiva";
  return null;
}
// El servidor DEBE revalidar igualmente: nunca confíes en el cliente

Punto crítico de seguridad: en un thick client, la validación en el cliente mejora la experiencia, pero el servidor siempre debe revalidar. El código del cliente es manipulable.

La evolución hacia la web

La web es, en esencia, una arquitectura cliente-servidor de 3 niveles que ha oscilado entre thin y thick a lo largo del tiempo:

timeline
    title Evolución del cliente web
    Web 1.0 : HTML estático : Thin client puro
    Server-side : JSP/PHP/Servlets : El servidor genera el HTML
    AJAX : Páginas dinámicas parciales : El cliente empieza a engordar
    SPA : Angular/React/Vue : Thick client en el navegador
    SSR / Hibrido : Next.js, etc. : Render mixto cliente-servidor

Etapas clave:

Web 1.0 (HTML estático): thin puro. El servidor entrega documentos.
Server-side rendering (JSP, PHP, Servlets): el servidor genera HTML dinámico por petición. Cliente ligero.
AJAX: el navegador empieza a pedir trozos de datos sin recargar la página. El cliente engorda.
SPA (Single Page Application): Angular, React, Vue. El navegador es un thick client que consume una API REST/GraphQL.
SSR / híbrido: se vuelve a renderizar parte en servidor (rendimiento, SEO) combinándolo con interactividad en cliente.

# Petición HTTP típica de un cliente web a una API REST (modelo 3-tier)
curl -X GET https://api.fiatc.example/polizas/42 \
     -H "Authorization: Bearer <token>" \
     -H "Accept: application/json"

Explicación: el navegador (tier 1) hace una petición HTTP al servidor de aplicaciones (tier 2), que a su vez consultará la BD (tier 3). El protocolo es HTTP, el formato JSON, y la autenticación viaja en una cabecera. Este es el esqueleto de prácticamente toda la web moderna.

Ventajas e inconvenientes

Ventajas	Inconvenientes
Centralización de recursos y seguridad	El servidor es un punto único de fallo (hay que replicarlo)
Mantenimiento y actualización centralizados (en 3-tier)	Dependencia de la red: latencia y fallos posibles
Escalabilidad del tier intermedio	Mayor complejidad que un sistema local
Separación física de responsabilidades	Coste de infraestructura y operación
Reutilización del servidor por muchos clientes	El protocolo y los contratos deben gestionarse con cuidado

Errores Comunes y Consejos

Confiar en la validación del cliente. En cualquier thick client, valida también en el servidor. El cliente es territorio hostil.
Confundir tier con layer. Tres niveles físicos no obligan a tres capas lógicas, ni al revés.
Meter lógica de negocio en la base de datos sin control. Heredado del 2-tier; dificulta pruebas y versionado. Úsalo solo con criterio.
Olvidar que la red falla. Toda llamada cliente-servidor puede dar timeout o error; diseña reintentos y manejo de errores.
No replicar el servidor. Un único servidor es un punto único de fallo; planifica alta disponibilidad.
Consejo: decide conscientemente cuánto poner en el cliente. Más lógica en cliente mejora la experiencia offline pero complica el despliegue y la seguridad.

Ejercicios

Ejercicio 1. Una empresa tiene una app de escritorio que se conecta directamente a la base de datos con la lógica de negocio dentro del ejecutable. Indica el modelo, sus dos principales problemas y a qué modelo migrarías.

Ejercicio 2. Clasifica como thin o thick: (a) una terminal que solo muestra lo que envía el servidor; (b) una SPA de React que valida formularios y cachea datos; (c) una página PHP que genera HTML en el servidor.

Ejercicio 3. Explica por qué validar una prima negativa solo en el navegador es insuficiente y qué debe hacer el servidor.

Soluciones

Solución 1. Es un modelo 2-tier con thick client. Problemas: (1) mantenimiento costoso, cada cambio exige reinstalar en cada PC; (2) escalabilidad limitada, cada cliente abre su propia conexión a la BD. Migración recomendada: 3-tier, introduciendo un servidor de aplicaciones que concentre la lógica y exponga una API.

Solución 2. (a) Thin. (b) Thick. (c) Thin (la lógica y el render están en el servidor; el navegador solo muestra HTML).

Solución 3. El código JavaScript del navegador es manipulable: un usuario puede saltarse la validación o enviar peticiones directas a la API. El servidor debe revalidar siempre la prima antes de persistirla, porque es la única frontera de confianza real.

Conclusión

La arquitectura cliente-servidor define cómo se reparte un sistema entre máquinas: clientes que piden y servidores que sirven. Hemos visto el paso del frágil 2-tier al robusto 3-tier, la tensión entre clientes ligeros y pesados, y cómo la web ha oscilado entre ambos extremos. Este reparto físico complementa el reparto lógico en capas de la lección anterior. A continuación daremos un salto cualitativo en la organización del interior del servidor: la Arquitectura Hexagonal (Puertos y Adaptadores), que protege el núcleo de dominio de los detalles de infraestructura e invierte la dependencia que en las capas clásicas apuntaba peligrosamente hacia la base de datos.

Arquitectura Cliente-Servidor

Contenido

El modelo cliente-servidor

Modelo de dos niveles (2-tier)

Modelo de tres niveles (3-tier)

Thin client vs thick client

La evolución hacia la web

Ventajas e inconvenientes

Errores Comunes y Consejos

Ejercicios

Soluciones

Conclusión

Curso de Arquitectura de Aplicaciones

Módulo 1: Fundamentos de la Arquitectura de Aplicaciones

Módulo 2: Principios y Tácticas de Diseño

Módulo 3: Estilos y Patrones Arquitectónicos

Módulo 4: Arquitecturas Distribuidas y Microservicios

Módulo 5: Arquitecturas Dirigidas por Eventos y Mensajería

Módulo 6: Diseño Dirigido por el Dominio (DDD)

Módulo 7: Datos y Persistencia

Módulo 8: Arquitectura en la Nube y Despliegue

Módulo 9: Calidad, Seguridad y Observabilidad

Módulo 10: Evolución, Gobernanza y Casos Prácticos