¿Qué es CQRS?

Casi todos los sistemas empiezan con un único modelo para todo. Un solo objeto Pedido se carga de la base de datos, se muta cuando el cliente cambia algo y se vuelve a leer cuando una página necesita mostrarlo. La misma forma sirve para la escritura y para la lectura. Es el diseño obvio y, durante mucho tiempo, es el correcto.

La tensión aparece más tarde. La forma que conviene para escribir —normalizada, validada, custodiando invariantes— rara vez es la forma que conviene para leer. Un panel quiere una fila ancha y desnormalizada que une seis tablas. El lado de escritura quiere esas seis tablas separadas para que cada una se mantenga consistente. Un mismo modelo ahora se estira en dos direcciones y no sirve bien a ninguna.

CQRS es la decisión de dejar de estirar.

El modelo mental: leer y escribir son problemas distintos

La idea central es casi vergonzosamente simple una vez que la ves. Escribir y leer no son dos operaciones sobre una misma cosa: son dos problemas distintos.

Las escrituras tratan de proteger invariantes. ¿Puede cancelarse este pedido? ¿Sigue disponible este asiento? ¿Deja esta transferencia la cuenta con saldo? Un modelo de escritura existe para decir no en el momento correcto. Es pequeño, normalizado y celoso de la consistencia.

Las lecturas tratan de responder preguntas rápido, en cualquier forma que necesite quien las llama. Un modelo de lectura existe para decir sí, aquí está: previamente unido, desnormalizado, indexado para la consulta exacta, a menudo cacheado. Nunca necesita hacer cumplir una regla, porque nunca cambia nada.

Forzar ambas tareas a través de un solo modelo significa que cada consulta paga por las garantías del lado de escritura, y cada escritura pelea contra la comodidad del lado de lectura. CQRS permite que cada lado sea honesto sobre para qué existe.

Cómo funciona

Los comandos y las consultas viajan por caminos distintos. Un comando (CancelarPedido) va al modelo de escritura, que lo valida contra el estado actual y, si se permite, persiste el cambio. Una consulta (ObtenerResumenDePedido) va a un modelo de lectura —una tabla, vista, caché o incluso una base de datos aparte— construido para responder exactamente esa pregunta.

El modelo de lectura no se mantiene solo. Algo tiene que propagar los cambios del lado de escritura al de lectura. Ese «algo» suelen ser eventos: el modelo de escritura emite un hecho cuando el estado cambia, y una proyección actualiza el modelo de lectura en respuesta. Por eso CQRS y los eventos se mencionan tan a menudo juntos: el mismo hecho que describe una escritura es justo lo que un modelo de lectura necesita para mantenerse al día.

Cómo se relaciona con event sourcing

CQRS suele emparejarse con event sourcing, y ambos se refuerzan con tal naturalidad que mucha gente los confunde. Son ideas separadas.

Event sourcing trata de cómo el lado de escritura almacena la verdad: como un registro solo-de-anexado de eventos en lugar de filas mutables. CQRS trata de mantener las lecturas y las escrituras como modelos distintos. Puedes hacer CQRS con dos tablas SQL comunes y ningún registro de eventos. Puedes hacer event sourcing con un solo modelo y nunca separar tus lecturas.

Pero juntos encajan. Si tu lado de escritura ya es un registro de eventos, construir modelos de lectura es solo plegar esos eventos en la forma que quiera una consulta, y puedes construir tantos modelos de lectura especializados como preguntas tengas, todos desde la misma fuente de verdad. Event sourcing te da el flujo; CQRS te da la libertad de proyectarlo de muchas maneras.

Cuándo usarlo

CQRS justifica su costo cuando las cargas de lectura y de escritura divergen de verdad:

• Las cargas de lectura y escritura escalan de forma distinta. Un sistema leído mil veces por cada escritura puede escalar sus modelos de lectura de forma independiente —réplicas, cachés, vistas desnormalizadas— sin tocar el camino de escritura.
• La forma de lectura pelea con la forma de escritura. Cuando tus consultas necesitan datos ensamblados desde muchos agregados, un modelo de lectura hecho a medida vence a joins cada vez más barrocos.
• Necesitas muchas vistas de los mismos datos. Reportes, búsqueda y la interfaz de la app pueden tener cada uno una proyección afinada a sus necesidades.
• Ya se combina con event sourcing. Si tus escrituras son eventos, CQRS es la forma natural de leerlos.

Cuándo no usarlo

El error más común es aplicar CQRS a un sistema entero por reflejo. Es un patrón para las partes de un dominio donde las lecturas y las escrituras realmente se separan, no un estilo de la casa. La mayoría de las aplicaciones tienen un puñado de esos puntos calientes y una larga cola de tablas comunes a las que un solo modelo sirve a la perfección.

Ideas clave

• CQRS separa el modelo de escritura del modelo de lectura porque cambiar el estado y consultarlo son problemas distintos con restricciones distintas.
• El lado de escritura protege invariantes; el lado de lectura responde preguntas rápido, en cualquier forma que necesite quien las llama.
• Los modelos de lectura se mantienen al día propagando los cambios —normalmente como eventos— desde el lado de escritura.
• Es distinto de event sourcing, pero se compone muy bien con él; cualquiera puede usarse por separado.
• Aplícalo de forma selectiva, en los puntos calientes donde un solo modelo realmente estorba. Para un CRUD común, un solo modelo sigue siendo la respuesta honesta.

La pregunta que responde CQRS no es «¿cómo almaceno mis datos?», sino «¿debería lo que hace cumplir mis reglas ser lo mismo que responde mis preguntas?». Cuando la respuesta es no, separarlos es todo el objetivo.