Cómo usar el patrón CQRS para mejorar escalabilidad y rendimiento

Patrón de diseño CQRS: cuándo usarlo y por qué no es para todos

Tiempo estimado de lectura: 4 min

Resumen rápido (lectores con prisa)

CQRS separa operaciones que modifican estado (Commands) de las que leen datos (Queries).

Úsalo cuando necesites escalado de lecturas, vistas desnormalizadas o múltiples proyecciones por consumidor.

Introduce consistencia eventual y mayor complejidad operativa (event bus, idempotencia, reintentos).

Implementación típica: write model ACID + event bus + proyectores + read model optimizado.

Patrón de diseño CQRS: ¿qué es y cómo funciona?

CQRS (Command Query Responsibility Segregation) extiende el principio CQS de Bertrand Meyer a nivel arquitectónico. La idea es sencilla:

• Commands = intenciones que cambian estado (ej. CrearPedido).
• Queries = lecturas sin efectos secundarios (ej. ObtenerPedidosUsuario).

Arquitectura típica

• Lado de escritura: valida reglas de negocio, persiste en DB normalizada (ACID) y publica eventos.
• Bus de eventos: Event bus recomendado (Kafka, RabbitMQ o SQS transportan los eventos).
• Proyectores (projectors): consumen eventos y actualizan vistas desnormalizadas.
• Lado de lectura: lee desde vistas optimizadas (Elasticsearch, MongoDB, Redis).

Referencia conceptual: Referencia conceptual

Ejemplo práctico (TypeScript, simplificado)

Command side

Command side:

class CrearPedidoCommand { constructor(public usuarioId:string, public items:any[]){ } }

class PedidoHandler {
  async execute(cmd: CrearPedidoCommand){
    const pedido = PedidoFactory.crear(cmd);
    await writeRepo.save(pedido); // BD transaccional
    eventBus.publish(new PedidoCreadoEvent(pedido.id, pedido.snapshot()));
  }
}

Query side (proyector)

Query side (proyector):

eventBus.subscribe('PedidoCreado', async (evt) => {
  await readRepo.upsert({ id: evt.pedidoId, usuarioId: evt.usuarioId, total: evt.total });
});

La UI consume readRepo: consultas rápidas, sin joins.

Por qué usar CQRS: beneficios reales

• Escalado independiente: replicas de lectura que soportan millones de consultas sin tocar la base transaccional.
• Consultas ultrarrápidas: vistas pre-agg y desnormalizadas adaptadas a cada cliente.
• Lógica de dominio limpia: los comandos alojan reglas complejas sin ensuciar las consultas.
• Seguridad y límites: segmentas permisos entre escritura y lectura.

Stack sugerido

• Comandos: NestJS + PostgreSQL
• Event bus: Kafka
• Lectura: Elasticsearch/OpenSearch o Redis para vistas calientes
• Frameworks: Axon (Java) para Event Sourcing/CQRS

El coste: por qué no es para todos

CQRS trae dos impuestos que muchos subestiman:

1. Consistencia eventual. Tras un comando exitoso, la vista puede tardar en actualizarse. La UI y procesos deben tolerar ese lag (read-your-writes, polling, optimistic updates).
2. Complejidad operativa. Monitoreo del bus, reintentos, idempotencia, versionado de eventos, proyecciones huérfanas. Debuggear fallos distribuidos se vuelve un arte oscuro.

Señales de alarma: equipo pequeño, dominio CRUD simple, SLA que exige consistencia inmediata. En esos casos, CQRS es over-engineering.

Cuándo aplicarlo (criterios claros)

Usa CQRS solo si encajan al menos dos de estos casos:

• Ratio lectura/escritura muy alto (p. ej. 100:1 o más).
• Vistas múltiples y complejas que requieren pre-agrupación o formato distinto por consumidor.
• Dominio con reglas de negocio complejas que complican las consultas si se mezclan.
• Ya trabajas con arquitectura basada en eventos o Event Sourcing.

Evítalo si:

• Tu app es formularios + listados simples.
• Tienes requisitos de consistencia inmediata estrictos.
• No hay capacidad operativa para mantener infra distribuida.

Migración práctica: cómo empezar sin detonarte

1. Identifica el “hot path” de lecturas lentas (métricas p95/p99).
2. Implementa un proyector que consuma eventos y mantenga una vista materializada mínima.
3. Redirige esas consultas al read model gradualmente.
4. Añade pruebas de integridad, idempotencia y observabilidad en el event bus.
5. Solo entonces extiende el patrón a otros contextos.

Herramientas útiles: Axon, EventStore, Kafka, y librerías CQRS como @nestjs/cqrs.

Conclusión y siguiente paso

El patrón de diseño CQRS te da independencia y rendimiento donde el modelo CRUD choca contra límites reales. Pero es cirugía mayor: pagas con latencia, operaciones y debugging distribuido. No lo adoptes por moda; adopta CQRS por necesidad demostrada.

Empieza pequeño: crea una proyección, mide el lag, valida la experiencia de usuario. En el próximo artículo mostraré una migración paso a paso desde un endpoint CRUD hacia una vista materializada con Kafka y un proyector en Node.js.

FAQ