CQRS y event sourcing

De la separación comando-consulta a CQRS

La idea empieza siendo pequeña. En Object-Oriented Software Construction (primera edición, 1988), Bertrand Meyer propuso la separación comando-consulta: todo método debe ser o bien un comando que cambia el estado y no devuelve nada, o bien una consulta que devuelve una respuesta y no cambia nada. Hacer una pregunta nunca debería cambiar la respuesta. Martin Fowler señala que la regla tiene excepciones razonables (sacar un elemento de una pila cambia la pila y a la vez devuelve el elemento), pero como norma por defecto hace que sea más fácil razonar sobre el código, porque las consultas pueden llamarse libremente, en cualquier orden, sin efectos secundarios.

Hacia 2010, Greg Young elevó el principio de los métodos a los modelos completos y llamó al resultado Command Query Responsibility Segregation (CQRS). En lugar de un único modelo de objetos, y normalmente un único conjunto de tablas, que sirve tanto para las actualizaciones como para las lecturas, el sistema tiene un modelo de escritura que gestiona los comandos y hace cumplir las reglas de negocio, y uno o más modelos de lectura con la forma de las preguntas que hacen los usuarios. La idea clave es que escribir y leer son trabajos distintos. Escribir necesita reglas estrictas, transacciones pequeñas y una estructura normalizada para que cada hecho se almacene una sola vez. Leer necesita velocidad, formas desnormalizadas que coincidan con las pantallas y los informes, y a menudo mucho más tráfico. Un único modelo que intenta hacer bien ambas cosas tiende a hacer mal las dos en cuanto el dominio se vuelve rico.

Qué cambia realmente CQRS

En el lado de escritura, un comando como WithdrawMoney(account 42, £50) llega a un manejador de comandos. El manejador carga el agregado correspondiente (el conjunto de datos que debe mantenerse consistente dentro de una transacción, un término del diseño guiado por el dominio que se trata en la Sección 5.7), le pide que aplique las reglas de negocio y guarda el resultado. Los comandos son solicitudes y pueden rechazarse: la cuenta puede estar bloqueada o los fondos pueden ser insuficientes. En el lado de lectura, una consulta como muéstrame los últimos 30 movimientos con el saldo acumulado se responde desde un modelo de lectura construido exactamente para esa pantalla, sin joins, sin lógica de negocio y sin bloqueos sobre las tablas de escritura.

Algo tiene que mantener actualizados los modelos de lectura. Esa tarea corresponde a una proyección: código que escucha los cambios del lado de escritura y actualiza un modelo de lectura. Las proyecciones pueden mantener una tabla de saldos, un índice de búsqueda de movimientos, un documento de extracto mensual y un almacén de características (feature store) para puntuar el fraude, cada uno a partir del mismo flujo de cambios. Por tanto, los modelos de lectura son datos derivados: siempre pueden desecharse y reconstruirse a partir del lado de escritura. Esa propiedad es la que hace seguro añadir un nuevo modelo de lectura el año que viene, o cambiar la forma de uno antiguo.

CQRS admite grados, y el más ligero suele ser todo lo que un sistema necesita. En el grado más ligero, los modelos de escritura y de lectura son clases distintas sobre la misma base de datos, y las lecturas se sirven mediante vistas o código de consulta dedicado. En el grado intermedio, los modelos de lectura viven en tablas separadas que se actualizan en la misma transacción que la escritura. En el grado más pesado, los modelos de lectura viven en almacenes distintos (un motor de búsqueda, una base de datos documental, una caché) y se actualizan de forma asíncrona a partir de eventos, lo que aporta escala y flexibilidad, pero también consistencia eventual. CQRS no requiere event sourcing, un intermediario de mensajes (message broker) ni microservicios; son decisiones independientes que a menudo, aunque no necesariamente, se toman juntas.

Event sourcing: el estado como una secuencia de hechos

La mayoría de los sistemas almacenan el estado actual. Cuando Asha retira £120, la fila de accounts pasa de £500 a £380 y el valor antiguo desaparece, a menos que alguien escriba también una fila de auditoría. El event sourcing, descrito por Martin Fowler en 2005, le da la vuelta a esto: el sistema almacena cada cambio como un evento inmutable en un log de solo anexado, y el estado actual es lo que se obtiene al reproducir los eventos en orden. Los eventos son la fuente de verdad; el saldo es un cálculo.

Los eventos se nombran en pasado porque registran hechos que ya han ocurrido y se han aceptado: AccountOpened, MoneyDeposited, MoneyWithdrawn. Un comando (WithdrawMoney) es una solicitud que puede rechazarse; un evento (MoneyWithdrawn) ya no puede rechazarse, solo compensarse con un evento posterior. Cada agregado tiene su propio flujo de eventos, numerado a partir de la versión 1, y el almacén garantiza que los eventos de un flujo se conservan en orden.

Reconstruir el estado es un plegado por la izquierda (left fold): se empieza sin nada, se aplica el primer evento, se aplica el segundo al resultado, y así sucesivamente. La función que aplica los eventos debe ser pura y determinista: no puede llamar a un reloj, a un generador de números aleatorios ni a otro servicio, porque reproducir los mismos eventos siempre debe dar el mismo estado. Cualquier valor que venga del exterior (un tipo de cambio, una marca de tiempo, una puntuación de fraude) se registra dentro del evento en el momento en que se decide por primera vez.

La escritura sigue un ciclo fijo. El manejador de comandos carga el flujo, lo pliega en el estado actual, ejecuta la regla de negocio y anexa los nuevos eventos con la versión que espera escribir. Si entretanto otro comando ha anexado eventos al mismo flujo, la anexión falla y el manejador vuelve a intentarlo con el estado actualizado. Es la concurrencia optimista de la Sección 7.3, aplicada por flujo, y es la razón por la que dos retiros simultáneos no pueden gastar ambos las mismas £100.

# A bank account as a stream of events, folded into current state.
# Amounts are in pence so that no floating-point rounding creeps in.
from functools import reduce

events = [
    {"v": 1, "type": "AccountOpened",  "overdraft_limit": 0},
    {"v": 2, "type": "MoneyDeposited", "amount": 50000},
    {"v": 3, "type": "MoneyWithdrawn", "amount": 12000},
    {"v": 4, "type": "MoneyDeposited", "amount": 7550},
    {"v": 5, "type": "MoneyWithdrawn", "amount": 30000},
]

def apply(state, e):                       # pure: old state + event -> new state
    if e["type"] == "AccountOpened":
        return {"balance": 0, "limit": e["overdraft_limit"], "version": e["v"]}
    sign = 1 if e["type"] == "MoneyDeposited" else -1
    return {**state, "balance": state["balance"] + sign * e["amount"], "version": e["v"]}

def decide_withdraw(state, amount):        # command side: check the rule, emit events
    if state["balance"] - amount < -state["limit"]:
        raise ValueError("insufficient funds")
    return [{"v": state["version"] + 1, "type": "MoneyWithdrawn", "amount": amount}]

now = reduce(apply, events, None)          # {'balance': 15550, 'limit': 0, 'version': 5}
as_at_v3 = reduce(apply, events[:3], None) # temporal query: balance 38000

-- An event store can be an ordinary table. The primary key enforces
-- optimistic concurrency: only one writer can append version 6.
CREATE TABLE account_events (
  account_id  uuid        NOT NULL,
  version     integer     NOT NULL,
  event_type  text        NOT NULL,
  data        jsonb       NOT NULL,
  recorded_at timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (account_id, version)
);

-- The command handler read the stream up to version 5, decided, and now appends:
INSERT INTO account_events (account_id, version, event_type, data)
VALUES ('2f9c0d6e-4a51-4c7e-9a43-6d1f2b7e8a10', 6, 'MoneyWithdrawn', '{"amount": 2000}');
-- If a concurrent command already appended version 6, this fails with a
-- unique violation; the handler reloads the stream and decides again.

Lo que te da el event sourcing

Una pista de auditoría completa por construcción. En un sistema basado en el estado, el log de auditoría es una segunda escritura que alguien puede olvidar, y puede no coincidir con los datos. En un sistema con event sourcing, el log son los datos, así que no puede desviarse de ellos. Los reguladores de la banca, los seguros y la sanidad lo valoran mucho.

Consultas temporales. ¿Cuál era el saldo a las 23:59 del 31 de marzo? o ¿Qué pedidos estaban en estado PREPARING cuando falló la pantalla de la cocina? se convierten en plegados sobre un prefijo de cada flujo, en lugar de en un trabajo forense sobre copias de seguridad.

Reconstrucciones y nuevos modelos de lectura. Como los modelos de lectura son derivados, un equipo puede corregir un bug en una proyección, borrar su salida y reproducir todos los eventos para producir una vista corregida. También puede construir, sobre todo el historial, un modelo de lectura en el que nadie pensó cuando se registraron los eventos, como un informe de la frecuencia con la que los clientes retiran efectivo durante la hora siguiente a cobrar.

Depuración y análisis hipotético (what-if). Copiar un flujo en un entorno de pruebas y reproducirlo recrea el estado exacto que causó un bug. Reproducir los mismos eventos con reglas modificadas muestra lo que habrían hecho las nuevas reglas.

Una fuente natural de eventos de integración. Los eventos pueden alimentar a otros servicios, aunque es mejor tratar los eventos almacenados en un flujo como un detalle privado del servicio propietario. Publicarlos directamente acopla a todos los consumidores al modelo interno; muchos equipos prefieren traducirlos a un conjunto más pequeño de eventos de integración públicos, diseñados como los contratos publicados de larga duración descritos en la Sección 6.4.

Snapshots y flujos largos

Plegar cinco eventos es instantáneo; plegar 400 000 eventos de una cuenta de comercio con mucho movimiento en cada comando no lo es. Un snapshot (instantánea) almacena el estado plegado de un flujo en una versión conocida, de modo que la carga pasa a ser leer el último snapshot y aplicar solo los eventos posteriores. Los snapshots son una caché, no una fuente de verdad: pueden borrarse y recrearse en cualquier momento, en segundo plano, sin detener el sistema. Tómalos cada N eventos o según un calendario, y guarda junto a ellos la versión del código que aplica los eventos, porque un snapshot producido por código antiguo es incorrecto en cuanto cambia la lógica del plegado.

Antes de recurrir a los snapshots, revisa el diseño del flujo. Los flujos muy largos suelen indicar que el agregado es demasiado grande. Una cuenta bancaria que dura 40 años puede modelarse como una serie de flujos más cortos, uno por periodo de extracto, cada uno abierto con un evento BalanceCarriedForward que registra el saldo de cierre del periodo anterior. Esto refleja cómo cierran los libros los contables, y mantiene cada flujo lo bastante corto como para cargarse rápidamente.

Los costos, dichos con franqueza

Complejidad y falta de familiaridad. El event sourcing cambia la forma en que cada desarrollador del equipo piensa en la persistencia. Preguntas sencillas como ¿qué clientes viven en Leeds? no pueden plantearse en absoluto al almacén de eventos; necesitan una proyección. Las herramientas para inspeccionar, migrar y reparar almacenes de eventos están menos maduras que las de las tablas relacionales, y menos ingenieros han operado un sistema así en producción.

Consistencia eventual de los modelos de lectura. Cuando las proyecciones se ejecutan de forma asíncrona, un usuario puede hacer un retiro y luego ver un saldo que todavía no lo incluye. Las mitigaciones habituales son devolver la nueva versión del flujo desde el comando y hacer que el lado de consulta espere hasta que su proyección haya procesado esa versión (una garantía de leer tus propias escrituras, como en la Sección 7.4); actualizar la interfaz de usuario de forma optimista a partir del resultado del comando; o actualizar los modelos de lectura críticos de forma síncrona en la misma transacción que la anexión. Las proyecciones también deben ser idempotentes y registrar la posición que han procesado, porque los eventos pueden entregarse más de una vez tras una caída.

Versionado de eventos. Los eventos se almacenan para siempre, así que su esquema nunca puede cambiarse sin más. Cuando MoneyDeposited incorpora un campo de moneda, años de eventos antiguos siguen sin tenerlo. Las técnicas habituales, catalogadas por Greg Young en Versioning in an Event Sourced System, incluyen los lectores tolerantes, que aportan valores por defecto para los campos que faltan; el upcasting (una función que convierte una versión antigua de un evento a la forma actual en el momento de leerlo, de modo que el código del dominio solo ve una versión); la introducción de un nuevo tipo de evento junto al antiguo; y, como último recurso, la copia de un flujo entero en uno nuevo con los eventos transformados. La Sección 7.7 trata las reglas generales de compatibilidad.

Borrar datos personales. Un log inmutable choca con el derecho de supresión que establece la legislación de protección de datos. La técnica habitual es el crypto-shredding (destrucción criptográfica): los campos personales de los eventos se cifran con una clave guardada por cliente en un almacén de claves aparte, y la supresión consiste en destruir esa clave para que el texto cifrado ya no pueda leerse. La alternativa es mantener los datos personales totalmente fuera de los eventos y almacenar solo una referencia a un registro que pueda borrarse. Si destruir una clave cuenta o no como supresión es una valoración jurídica más que técnica, así que acuerda el enfoque con el delegado de protección de datos; la Sección 8.7 trata las obligaciones más amplias.

Carga operativa. Reconstruir una proyección sobre mil millones de eventos puede llevar horas, así que los equipos necesitan una forma de ejecutar la nueva proyección junto a la antigua y cambiar a ella cuando se ponga al día. Los almacenes de eventos crecen sin límite, y con ellos crecen el almacenamiento y los tiempos de copia de seguridad y de reproducción.

Cuándo no usar ninguno de los dos, y errores comunes

Ninguno de los dos patrones encaja en un dominio que consiste sobre todo en formularios sobre datos, en un equipo pequeño que construye su primera versión, ni en un sistema cuyo único problema es la carga de lectura (una réplica de lectura o una caché es mucho más barata). El event sourcing también encaja mal donde los datos deben borrarse de verdad bajo demanda y en gran volumen, o donde la mayoría de las consultas abarcan muchos agregados, ya que cada una de esas consultas necesita su propia proyección.

Los errores comunes son previsibles. Los equipos aplican los patrones a todo el sistema en lugar de a un contexto. Exponen los eventos almacenados como contrato público, lo que congela su modelo interno. Ponen valores derivados o llamadas externas en la función que aplica los eventos, de modo que la reproducción da respuestas distintas. Diseñan los eventos como blobs genéricos AccountUpdated, que registran que algo cambió, pero no qué ocurrió ni por qué, y pierden la mayor parte del valor. Y olvidan que un modelo de lectura es una caché: empiezan a escribir en él directamente, y a partir de ese momento ya no puede reconstruirse.

Usada de forma selectiva, la combinación es potente. Una plataforma de reparto de comida podría aplicar event sourcing al ciclo de vida del pedido (realizado, aceptado, en preparación, recogido, entregado, reembolsado), porque las disputas y los reembolsos necesitan el historial exacto, y mantener las cartas, los perfiles de los restaurantes y la configuración de los usuarios como tablas ordinarias. Un banco podría aplicar event sourcing al libro mayor y a los pagos y almacenar de forma convencional los datos de contacto de los clientes, lo que además mantiene la mayor parte de los datos personales fuera del log inmutable.