CQRS

Resumen

CQRS —Command Query Responsibility Segregation— es un patrón que propone separar las operaciones que modifican estado (commands) de las que lo consultan (queries). En lugar de tener un solo modelo de datos que sirve tanto para escribir como para leer, CQRS usa dos: un modelo de escritura optimizado para consistencia y validación, y uno o varios modelos de lectura optimizados para consultas rápidas.

Importa porque en sistemas complejos, las necesidades de lectura y escritura son radicalmente distintas. Una pantalla de dashboard necesita datos agregados, desnormalizados y rápidos. Una operación de escritura necesita validar reglas de negocio, mantener integridad referencial y garantizar consistencia. Forzar que ambos compartan el mismo modelo produce un modelo que no es bueno para ninguna de las dos cosas.

CQRS suele combinarse con Event Sourcing —los eventos son la fuente de verdad para las escrituras, y las proyecciones construyen los modelos de lectura— y con mensajería asíncrona para sincronizar ambos lados.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

La boletería y la cartelera de un cine. La boletería vende entradas —operación de escritura— y necesita saber exactamente qué butacas están ocupadas, en tiempo real. La cartelera muestra qué películas hay —operación de lectura— y se actualiza cada tanto. Son dos sistemas distintos que comparten la misma información, pero nadie le pregunta a la boletería qué películas hay en cartel ni le pide a la cartelera que venda entradas.

Uso práctico

• ✅ Consultas complejas: el modelo de lectura puede estar desnormalizado, pre-agregado y optimizado para cada pantalla.
• ✅ Escalabilidad independiente: las lecturas —que suelen ser el 90% del tráfico— escalan por separado.
• ✅ Seguridad: comandos y queries pueden tener reglas de autorización distintas.
• ❌ Complejidad adicional: para CRUD simple, CQRS es sobre-ingeniería. Solo se justifica cuando el desbalance entre lecturas y escrituras es significativo.
• ❌ Consistencia eventual: si el modelo de lectura se actualiza asíncronamente, el usuario puede ver datos desactualizados por unos milisegundos o segundos.

CQRS no es una arquitectura completa: es una decisión de diseño que aplicás a partes específicas del sistema donde la separación aporta valor. No todo el sistema necesita CQRS.

Ejemplo trabajado: dashboard con CQRS

Un panel de administración muestra métricas agregadas: ventas por día, top 10 productos, clientes nuevos. Sin CQRS, cada consulta hace joins pesados sobre las tablas de escritura. Con CQRS, un proceso escucha eventos del modelo de escritura y actualiza un modelo de lectura desnormalizado —una tabla daily_sales_summary pre-agregada—. El dashboard consulta esa tabla en milisegundos. Las escrituras siguen su camino optimizado para integridad transaccional.

Evidencia

• Wikipedia, CQRS explica la separación de comandos y queries, la sincronización entre modelos y la relación con Event Sourcing.