Lección 217: Cuándo y por qué usar CQRS

En la lección anterior conocimos los principios básicos de CQRS. Ahora vamos a profundizar y entender cómo este patrón convive con otras soluciones arquitectónicas, y dónde realmente merece la pena aplicarlo.

Cómo conviven CQRS y Saga

¿Recuerdas nuestra querida Saga de las lecciones anteriores? Pues bien, CQRS y Saga son como la pizza con piña. O como el caramelo salado. Alguien dirá que es una combinación rara, pero los que la han probado saben que puede estar rica.

Veamos un ejemplo concreto. Imagina que estás desarrollando un sistema para una aerolínea:

• Saga se encarga de todo el proceso de reserva: desde la elección del asiento hasta el pago
• CQRS ayuda a que el sistema no se caiga cuando miles de usuarios buscan billetes al mismo tiempo

¿Cómo funciona esto junto?

1. Los comandos (escritura de datos) pasan por la Saga, asegurando la consistencia de todas las operaciones
2. Las consultas (lectura) se procesan por separado mediante CQRS, sin interferir con el proceso de reserva

Dónde CQRS realmente dio en el clavo

Ahora veamos casos reales. Y no, no voy a volver a hablar de Amazon y Netflix — tomemos ejemplos más cercanos.

Imagina que un conocido trabajó en una empresa que hacía un sistema de reservas online para una cadena de restaurantes. Al principio todo iba genial: un servicio CRUD sencillo con Spring Data JPA funcionaba de maravilla. Pero entonces llegó el 'Día Negro': el restaurante lanzó la promo "Todos los sushi casi gratis". El sistema se cayó en 15 minutos: demasiada gente intentaba reservar mesas al mismo tiempo.

¿Cómo lidiar con eso? Se puede implementar CQRS:

• Para la escritura (reservas) — Spring Data JPA con PostgreSQL
• Para la lectura (búsqueda de mesas libres) — Spring Cache con Caffeine o Hazelcast in-memory data grid
• Como broker de eventos para la sincronización — Spring Cloud Stream con Kafka

¿Resultado? El sistema no solo aguantó la siguiente promo, sino que además se volvió mucho más cómodo de desarrollar: cada parte hace exactamente lo que debe.

Dónde CQRS puede volverse en tu contra

Ahora hablemos de lo triste. He visto proyectos donde CQRS se convertía en un monstruo de Frankenstein. Aquí los errores típicos:

1. "¡Vamos a separar todo!" Los desarrolladores se entusiasmaron tanto con la idea de separar que crearon modelos distintos para cada operación. Al final un CRUD simple se convirtió en una nave espacial con motor warp.
2. "¿Para qué queremos consistencia?" Algunos olvidan que siempre hay un retraso entre escribir los datos y que aparezcan en el read-model. Y si tus usuarios ven datos distintos en pantallas diferentes, no es muy bueno.
3. "¡CQRS va a resolver todos nuestros problemas!" Spoiler: no, no lo hará. CQRS es como una salsa picante: funciona genial en el plato adecuado, pero no deberías echarla en el café de la mañana.

Alternativas a CQRS

A veces CQRS es como matar moscas a cañonazos. Veamos las alternativas:

1. Caché A menudo un simple caché resuelve el 80% de los problemas de rendimiento de lectura. Y es mucho más fácil de mantener.
2. Vistas materializadas En PostgreSQL puedes crear vistas materializadas (view) para reportes complejos. A veces eso es suficiente.
3. Escalado vertical Sí, no es muy trendy. Pero a veces es más sencillo comprar un servidor más potente que complicar la arquitectura.

Cuándo realmente vale la pena usar CQRS

1. Tienes requisitos realmente diferentes para lectura y escritura Por ejemplo, la escritura necesita ser estrictamente consistente y la lectura lo más rápida posible.
2. La carga de lectura y escritura difiere mucho Ejemplo clásico: una red social donde una publicación recibe miles de visualizaciones.
3. Ya usas Event Sourcing CQRS complementa muy bien a Event Sourcing. Pero de eso hablaremos en la próxima lección...

Conclusión

CQRS es una herramienta poderosa, pero hay que usarla con cuidado. Como dice el líder del equipo (¿qué líder del equipo? ¡Prácticamente cualquiera!): "No compliques donde puedes simplificar. Y no simplifiques donde hace falta complicar".

La próxima vez pasaremos a la práctica y escribiremos un servicio CQRS real. ¡Preparad vuestras IDE!