CQRS: Principios, Sincronización y Gestión de Complejidad

Una arquitectura convencional trata los sistemas como simples almacenes CRUD, centralizando las operaciones como: crear, leer, actualizar y eliminar registros. En proyectos pequeños es completamente funcional, pero cuando el proyecto grandes se vuelve mas complejo, es ahí, donde surge la necesidad de implementar nuevas estrategias como CQRS.

Con CQRS, la infraestructura de lectura puede escalar de forma independiente de la de escritura. En plataformas donde el volumen de consultas supera ampliamente al de mutaciones —catálogos de comercio electrónico, redes sociales—, esta separación reduce costes operativos: las réplicas de lectura se distribuyen geográficamente o se alojan en motores de búsqueda especializados, mientras el modelo de escritura permanece centralizado para proteger la integridad de las reglas de dominio.

Los beneficios también se reflejan en el código. Un modelo de dominio que carga con responsabilidades de persistencia y de lectura tiende a volverse difícil de mantener; separar ambos lados permite reducir la implementacion de funcionalidades que reducen la optimización en el sistema.

Un comando representa la intención de cambiar el estado de la aplicación y captura una tarea concreta del proceso de negocio. 'Reservar habitación de hotel' comunica una acción semántica clara, distinta de una actualización genérica sobre una tabla. Antes de surtir efecto, el comando atraviesa capas de autorización, validación de reglas y procesamiento transaccional; el objetivo del lado de escritura es que cada cambio preserve los invariantes del dominio.

En entornos .NET es habitual usar la biblioteca MediatR para despachar comandos hacia sus Command Handlers, que coordinan la ejecución, invocan las entidades de dominio y persisten los resultados. Una práctica frecuente en arquitecturas maduras es que el comando devuelva un resultado mínimo —un número de versión del agregado, por ejemplo— para evitar que el cliente tenga que consultar de inmediato si la acción tuvo éxito.

public class ReservarHabitacionCommandHandler
    : IRequestHandler<ReservarHabitacionCommand, ResultadoComando>
{
    private readonly IHabitacionRepository _repositorio;

    public ReservarHabitacionCommandHandler(IHabitacionRepository repositorio)
    {
        _repositorio = repositorio;
    }

    public async Task<ResultadoComando> Handle(
        ReservarHabitacionCommand comando, CancellationToken ct)
    {
        var habitacion = await _repositorio.ObtenerPorIdAsync(comando.HabitacionId, ct);

        habitacion.Reservar(comando.FechaEntrada, comando.FechaSalida, comando.HuespedId);

        await _repositorio.GuardarAsync(habitacion, ct);

        return new ResultadoComando(exito: true, version: habitacion.Version);
    }
}

Las consultas tienen un único objetivo: recuperar información sin alterar el estado del sistema. Al no producir efectos secundarios, pueden resolverse con modelos de lectura diseñados a la medida de cada pantalla o reporte, con datos desnormalizados, agregados precomputados o índices especializados que aceleran el tiempo de respuesta.

Recomendado Arquitectura de Software

Arquitectura Hexagonal: ¿Vale la Pena en tu Proyecto?

Hace 25 días Leer ahora

El lado de consulta puede apoyarse en tecnologías distintas a las del lado de escritura: una base relacional para las transacciones complejas y una base de documentos o un motor de búsqueda para servir las consultas de la interfaz. Esta persistencia políglota evita uniones de tablas pesadas y reduce la contención de bloqueos en el almacén de datos principal.

public class ObtenerDisponibilidadQueryHandler
    : IRequestHandler<ObtenerDisponibilidadQuery, DisponibilidadViewModel>
{
    private readonly IMongoCollection<VistaDisponibilidad> _vistaLectura;

    public ObtenerDisponibilidadQueryHandler(IMongoDatabase db)
    {
        _vistaLectura = db.GetCollection<VistaDisponibilidad>("vista_disponibilidad");
    }

    public async Task<DisponibilidadViewModel> Handle(
        ObtenerDisponibilidadQuery query, CancellationToken ct)
    {
        var filtro = Builders<VistaDisponibilidad>.Filter
            .Eq(v => v.HotelId, query.HotelId);

        var vista = await _vistaLectura.Find(filtro).FirstOrDefaultAsync(ct);

        return DisponibilidadViewModel.DesdeVista(vista);
    }
}

Cuando CQRS emplea modelos de datos físicamente separados, aparece el reto de mantenerlos sincronizados. Tras una operación exitosa en el modelo de escritura, los cambios deben propagarse al modelo de lectura, un proceso que suele ocurrir de forma asíncrona mediante buses de eventos o colas de mensajes: es el origen de la consistencia eventual.

Bajo este esquema, un usuario puede ver información ligeramente desactualizada durante un intervalo que en la práctica suele medirse en milisegundos. La demora es aceptable en muchos contextos de negocio, aunque obliga a diseñar interfaces que la gestionen, con optimismo en la interfaz o técnicas de compensación. Alcanzar una escalabilidad horizontal masiva en sistemas distribuidos suele requerir relajar las garantías de consistencia inmediata, tal como plantea el teorema CAP.

Una confusión habitual es asumir que CQRS exige Event Sourcing. Son patrones independientes que se combinan bien, pero no se necesitan mutuamente: CQRS segrega la lectura de la escritura, mientras Event Sourcing cambia la forma de almacenar el estado, guardando la secuencia completa de eventos inmutables en lugar de solo el valor actual.

Cuando ambos se combinan, el almacén de eventos actúa como modelo de escritura y fuente única de verdad; el modelo de lectura se construye procesando esos eventos para generar proyecciones optimizadas. Esta combinación facilita la reconstrucción histórica del estado y la auditoría nativa, aunque incrementa la carga operativa y la curva de aprendizaje del equipo.

CQRS introduce componentes adicionales: despachadores de comandos, procesadores de proyecciones, mecanismos de sincronización. En aplicaciones con lógica de negocio simple, este patrón puede convertirse en sobreingeniería que reduce la productividad sin un beneficio real.

"La mayoría de los sistemas encaja mejor en un modelo CRUD; CQRS debe aplicarse solo en porciones específicas de un sistema."

La dificultad también aparece en la evolución del esquema de eventos y modelos de datos. Modificar la estructura de un evento en un sistema con Event Sourcing exige técnicas como los upcasters, funciones que transforman esquemas antiguos al formato actual, o migraciones complejas, dado que los eventos históricos no se pueden alterar.

Recomendado Arquitectura de Software

FaaS en 2026: Costos Ocultos y el Salto a WebAssembly

Hace 26 días Leer ahora

Un estudio sobre programación de vuelos interactivos ilustra la escalabilidad horizontal de CQRS. En el siguiente cuadro se observa la separacion del modelo de escritura, donde se validan los cambios; del modelo de lectura, donde se consultan los horarios. Esta separacion permitió manejar volúmenes de datos masivos con tiempos de respuesta razonables en la nube.

El estudio utilizó agregados que definen unidades transaccionales pequeñas, lo que elevó el nivel de concurrencia y redujo el coste de cada transacción. Los resultados registraron una escalabilidad lineal tanto en el modelo de lectura como en el de escritura al añadir más nodos, y confirmaron la eficacia del patrón para soluciones de baja latencia y alta tasa de solicitudes.

Probar sistemas basados en CQRS y Event Sourcing exige un enfoque distinto al de las aplicaciones tradicionales. La lógica de negocio se valida con pruebas de estilo 'dado-cuando-entonces': se configuran eventos pasados, se emite un comando y se verifican los nuevos eventos generados, sin necesidad de interactuar con bases de datos o colas de mensajes reales.

Las pruebas de integración resultan críticas para confirmar que las proyecciones se actualizan correctamente y que los manejadores de eventos son idempotentes: procesar el mismo evento varias veces no debe alterar el resultado final, algo esencial cuando la entrega de mensajes se garantiza 'al menos una vez'. El área de pruebas crece frente a los sistemas CRUD, a cambio de una mayor confianza en la estabilidad de la lógica de dominio a largo plazo.

El cumplimiento del Reglamento General de Protección de Datos (GDPR) plantea un desafío para la naturaleza inmutable del almacén de eventos: el derecho al olvido exige eliminar datos personales, algo que choca con la prohibición de borrar registros en un sistema de solo anexión. Las soluciones habituales incluyen almacenar los datos sensibles fuera del almacén de eventos y referenciarlos por identificador, o aplicar cifrado por eliminación de clave (crypto-shredding), donde borrar la clave de cifrado vuelve el dato irrecuperable.

Ignorar estos requisitos desde el diseño inicial puede comprometer la viabilidad legal del sistema. Algunos equipos optan por anonimizar la información en lugar de borrar los eventos, lo que conserva el historial de auditoría sin exponer datos personales; la decisión depende del nivel de exigencia regulatoria y de la arquitectura del almacén de datos.

CQRS no resuelve todos los problemas de software: es una herramienta especializada para dominios donde la complejidad de la lógica o los requisitos de rendimiento superan lo que un modelo CRUD puede sostener. La flexibilidad que gana un equipo al adoptarlo tiene como contraparte una responsabilidad mayor en la gestión de la consistencia y la infraestructura, y esa cuenta solo sale a favor cuando el dominio realmente lo exige. Aplicado con disciplina, en contextos delimitados y críticos, el patrón permite construir sistemas capaces de escalar cada lado por separado sin sacrificar la corrección del negocio; aplicado sin ese criterio, añade piezas móviles que ningún equipo pequeño necesita mantener.

CQRS es una herramienta óptima cuando existe mucha asimetría entre lectura y escritura, no una solución universal. El caso de programación de vuelos lo confirma: la escalabilidad lineal en ambos modelos no provino de separar lecturas y escrituras por principio, sino de combinar esa separación con agregados pequeños que redujeron el coste transaccional y elevaron la concurrencia.

Como toda herramienta, su implementación debe tener fundamento en sus limitaciones y consistencia. Gestionarla tiene un coste operativo que solo se justifica cuando el dominio lo exige. Aplicado sin él sin evaluar las necesidades reales, añade piezas que ningún equipo pequeño necesita mantener.