La arquitectura cliente-servidor es el modelo en el que un programa (el cliente) pide un servicio y otro programa (el servidor) lo atiende, normalmente a través de una red. Para el TAI lo importante no es solo la definición, sino distinguir sus variantes: arquitectura de 2 capas, de 3 capas y en n capas, y saber qué hace cada capa en cada una. Es un concepto que conecta redes, bases de datos y desarrollo de sistemas, así que suele aparecer formulado desde ángulos distintos en el examen. Aquí lo explicamos sin liarte, con ejemplos y una tabla comparativa.
En este artículo
- ¿Qué es la arquitectura cliente-servidor?
- ¿Qué diferencia hay entre 2 capas, 3 capas y n capas?
- ¿Qué ventajas e inconvenientes tiene cada modelo?
- ¿Cómo se aplica esto a las aplicaciones web actuales?
- ¿Qué confunde más a quien estudia esto por primera vez?
- Preguntas frecuentes
¿Qué es la arquitectura cliente-servidor?
En una arquitectura cliente-servidor hay dos roles claramente separados:
- Cliente: inicia la petición. Puede ser un navegador, una aplicación de escritorio o una app móvil.
- Servidor: espera peticiones y responde. Gestiona los recursos compartidos: datos, lógica de negocio o archivos.
Es el modelo opuesto a una arquitectura entre iguales (peer to peer), donde todos los nodos pueden actuar como cliente y como servidor a la vez. En el temario del TAI, cliente-servidor es el modelo de referencia porque es el que usan la inmensa mayoría de sistemas de la Administración.
¿Qué diferencia hay entre 2 capas, 3 capas y n capas?
La diferencia está en cuántas responsabilidades se separan y dónde vive cada una. Las tres capas típicas de cualquier sistema son: presentación (interfaz), lógica de negocio (procesamiento) y datos (almacenamiento).
| Modelo | Cómo se reparten las capas | Ejemplo típico |
|---|---|---|
| 2 capas | El cliente asume presentación y lógica de negocio; el servidor solo gestiona los datos. | Aplicación de escritorio que se conecta directamente a una base de datos. |
| 3 capas | Presentación, lógica de negocio y datos viven en tres niveles separados. | Web con navegador, servidor de aplicaciones y servidor de base de datos independientes. |
| N capas | Se añaden más niveles intermedios: seguridad, caché, integración con otros sistemas. | Sistemas de la Administración electrónica con pasarela de pago, autenticación y varios servicios internos. |
¿Qué ventajas e inconvenientes tiene cada modelo?
Cuantas menos capas, más simple es de montar, pero menos flexible resulta cuando el sistema crece:
- 2 capas: rápido de implementar, pero cada cliente necesita conocer la estructura de la base de datos, lo que complica el mantenimiento y la seguridad.
- 3 capas: separa mejor las responsabilidades, facilita cambiar una capa sin tocar las demás (por ejemplo, cambiar el gestor de base de datos sin rehacer la interfaz) y mejora la seguridad, porque el cliente ya no accede a los datos de forma directa.
- N capas: máxima flexibilidad y escalabilidad, pero también más complejidad de diseño, más puntos de fallo posibles y más carga de administración.
En el examen suele preguntarse por qué la arquitectura de 3 capas es la más habitual en sistemas de la Administración: la respuesta corta es que equilibra seguridad, mantenimiento y coste de desarrollo mejor que las otras dos opciones.
¿Cómo se aplica esto a las aplicaciones web actuales?
Cualquier aplicación web moderna es, en el fondo, cliente-servidor en 3 capas o más:
- El navegador (cliente) pinta la interfaz.
- Un servidor de aplicaciones procesa la lógica de negocio, normalmente a través de una API.
- Un servidor de base de datos guarda y devuelve la información.
Cuando esa comunicación entre capas se hace a través de servicios web (por ejemplo API REST), estás viendo el mismo concepto de cliente-servidor aplicado con un protocolo concreto encima. Por eso conviene repasar ambos temas juntos: la arquitectura explica el reparto de responsabilidades, y el protocolo explica cómo se comunican entre sí.
¿Qué confunde más a quien estudia esto por primera vez?
Hay dos errores habituales que conviene tener localizados antes del examen:
- Confundir capa con máquina física. Las tres capas pueden estar en tres servidores distintos, pero también pueden convivir en la misma máquina. Lo que define la arquitectura es la separación lógica de responsabilidades, no dónde esté instalado cada componente.
- Pensar que más capas siempre es mejor. Añadir niveles intermedios (caché, balanceadores, pasarelas de autenticación) aporta escalabilidad, pero también más piezas que pueden fallar y más trabajo de mantenimiento. La pregunta correcta no es "cuántas capas tiene el sistema ideal", sino "qué necesita este sistema en concreto".
Tenerlo claro te ahorra dudas frente a preguntas de examen que plantean un caso práctico y piden identificar qué modelo se está describiendo.
Arquitecturas, metodologías, bases de datos y todo lo que cae del bloque más técnico de desarrollo, explicado sin liarte y con ejemplos como este.
Preguntas frecuentes
¿Qué modelo es el más habitual en los sistemas de la Administración?
El de 3 capas, porque separa bien presentación, lógica de negocio y datos, y ese reparto facilita el mantenimiento y refuerza la seguridad frente al modelo de 2 capas.
¿Es lo mismo cliente-servidor que peer to peer?
No. En cliente-servidor los roles están fijos: uno pide y otro responde. En peer to peer, cualquier nodo puede actuar como cliente y como servidor según el momento.
¿La arquitectura de n capas es siempre mejor que la de 3 capas?
No necesariamente. Añade flexibilidad, pero también complejidad de diseño y de administración. Para un sistema sencillo, 3 capas suele ser suficiente y más fácil de mantener.
¿Este tema entra en el Bloque III o en el Bloque IV?
La arquitectura cliente-servidor, como concepto de diseño de sistemas, se trabaja habitualmente dentro del Bloque III (Desarrollo de Sistemas), aunque se apoya en conceptos de redes que forman parte del Bloque IV.
¿Qué relación tiene con las API REST y SOAP?
Las API son el mecanismo de comunicación entre las capas de una arquitectura cliente-servidor distribuida. La arquitectura define el reparto de responsabilidades; el protocolo define cómo hablan entre sí esas capas.
Para completar este bloque, puedes seguir con API REST vs SOAP para el TAI y con Modelo OSI y TCP/IP para el TAI, que explica cómo viaja la información entre esas capas a nivel de red.