Arquitecturas orientadas al servidor

Estas arquitecturas definen cómo se organiza la lógica de negocio, el acceso a datos y la comunicación en el lado del servidor.

Monolito clásico

Toda la aplicación (frontend, backend y acceso a base de datos) vive en un único bloque de código que se despliega como una sola unidad.

Ventajas:

• Simple de desarrollar y desplegar al inicio.
• Fácil de depurar: todo el flujo está en un mismo proceso.
• Sin latencia de red entre componentes internos.

Desventajas:

• Escala mal: hay que replicar toda la aplicación aunque solo un módulo esté bajo carga.
• Un fallo puede tumbar el sistema completo.
• A medida que crece, se vuelve difícil de mantener.

Ideal para productos mínimos viables (MVP), proyectos pequeños y equipos reducidos.

Monolito modular

Un monolito cuyo código está organizado internamente en módulos bien definidos y desacoplados. Cada módulo tiene sus propias responsabilidades y fronteras claras, aunque todo se despliega como una única unidad.

Ventajas:

• Mantiene la simplicidad operacional del monolito.
• Facilita la migración futura a microservicios módulo a módulo.
• Equipos pueden trabajar en módulos distintos con menos fricción.

Desventajas:

• Requiere disciplina de equipo para mantener los límites entre módulos.
• Sigue siendo una única unidad de despliegue.

Ideal para proyectos en crecimiento que anticipan mayor complejidad pero aún no justifican microservicios.

SOA (Service-Oriented Architecture)

La aplicación se divide en servicios de grano grueso que se comunican a través de un bus empresarial centralizado (Enterprise Service Bus, ESB). Es el predecesor directo de los microservicios.

Ventajas:

• Mejor separación de responsabilidades que el monolito.
• Reutilización de servicios entre aplicaciones distintas.

Desventajas:

• El ESB se convierte en un cuello de botella y punto único de fallo.
• Complejidad alta de configuración y mantenimiento.
• Tecnología asociada a entornos corporativos legacy (SOAP, WSDL, XML).

Ideal para entornos empresariales con sistemas heredados. Los microservicios son su evolución moderna.

Microservicios

La aplicación se descompone en servicios pequeños e independientes, cada uno responsable de un dominio concreto, con su propia base de datos y ciclo de vida de despliegue.

Ventajas:

• Cada servicio escala de forma independiente.
• Un fallo en un servicio no tiene por qué tumbar el resto.
• Equipos autónomos pueden elegir tecnologías distintas por servicio.
• Despliegues más frecuentes y seguros.

Desventajas:

• Alta complejidad operacional: redes, monitoreo distribuido, consistencia de datos eventual.
• La comunicación entre servicios introduce latencia.
• Requiere infraestructura madura (Kubernetes, service mesh, observabilidad).

Ideal para productos maduros con equipos grandes y dominio bien comprendido (Netflix, Amazon, Uber).

Serverless / FaaS (Function as a Service)

El código se organiza en funciones pequeñas y efímeras que se ejecutan en respuesta a eventos. El proveedor cloud gestiona toda la infraestructura subyacente.

Ventajas

• Escala automáticamente de cero a miles de instancias.
• Se paga solo por el tiempo de ejecución real.
• Sin gestión de servidores ni sistemas operativos.

Desventajas

• Cold starts: la primera invocación puede ser lenta si la función estaba inactiva.
• Límites de tiempo de ejecución (generalmente hasta 15 minutos).
• Dependencia del proveedor (vendor lock-in): AWS Lambda, Google Cloud Functions, etc.
• Difícil de depurar y probar localmente.

Ideal para APIs event-driven, procesamiento de colas, tareas asíncronas y tráfico irregular.

API event-driven

Una API event-driven no es exactamente un tipo de API en el sentido tradicional, sino un estilo de comunicación donde el flujo no lo inicia el cliente preguntando, sino que el sistema notifica cuando algo ocurre.

En una API tradicional (REST), la comunicación es pull: el cliente pregunta, el servidor responde, y ahí termina la interacción.

• Cliente: "¿Hay pedidos nuevos?" → Servidor: "Sí, aquí tienes"
• Cliente: "¿Hay pedidos nuevos?" → Servidor: "No"
• Cliente: "¿Hay pedidos nuevos?" → Servidor: "No"

En una API event-driven, la comunicación es push: el servidor notifica al cliente cuando ocurre algo, sin que este tenga que preguntar.

• Servidor: "Oye, acaba de crearse un pedido nuevo"
• Servidor: "Oye, el pedido 42 cambió de estado"

Es muy habitual que un sistema use ambos estilos a la vez: REST para las operaciones CRUD normales y event-driven para las partes que necesitan tiempo real o procesamiento asíncrono.

Formas de implementarla:

• WebSockets — Conexión bidireccional persistente.
• Server-Sent Events (SSE) — Canal unidireccional del servidor al cliente.
• Webhooks — El servidor llama a una URL del cliente cuando ocurre un evento. No hay conexión persistente.
• Message Brokers (Kafka, RabbitMQ) — Comunicación entre servicios backend a través de una cola de mensajes. El productor publica un evento y los consumidores lo reciben cuando están listos.

Event-Driven Architecture (EDA)

Los componentes del sistema no se llaman directamente entre sí, sino que se comunican publicando y consumiendo eventos a través de un bus de mensajes.

Ventajas:

• Alto desacoplamiento: el productor no sabe quién consume sus eventos.
• Muy resiliente: si un consumidor falla, los eventos se procesan cuando se recupera.
• Ideal para alta concurrencia y procesamiento asíncrono.

Desventajas:

• El flujo de datos es difícil de trazar y depurar.
• La consistencia de datos es eventual, no inmediata.
• Requiere infraestructura adicional (Kafka, RabbitMQ, etc.).

Ideal para sistemas distribuidos con alta carga, pipelines de datos y dominios donde los eventos del negocio son ciudadanos de primera clase.

CQRS + Event Sourcing

CQRS (Command Query Responsibility Segregation) separa las operaciones de escritura (Commands) de las de lectura (Queries) en modelos distintos. Event Sourcing complementa esto almacenando cada cambio de estado como un evento inmutable en lugar de sobrescribir datos.

Ventajas:

• Lectura y escritura pueden escalar de forma independiente.
• El Event Store actúa como registro de auditoría completo e inmutable.
• Permite reconstruir el estado en cualquier punto del tiempo.

Desventajas:

• Alta complejidad de implementación y mantenimiento.
• Consistencia eventual entre el modelo de escritura y el de lectura.
• Curva de aprendizaje elevada.

Ideal para sistemas financieros, de auditoría, reservas, o cualquier dominio donde el historial de cambios sea tan importante como el estado actual.