CQRS O CRUD TRADICIONAL: ¿CUÁNDO CONVIENE SEPARAR LECTURA Y ESCRITURA?

En el diseño de software, una de las decisiones de arquitectura más recurrentes es elegir entre el enfoque clásico CRUD, Create, Read, Update, Delete y el patrón CQRS, Command Query Responsibility Segregation. La clave está si las necesidades de lectura y de escritura del sistema son realmente diferentes

CRUD

El CRUD tradicional utiliza un único modelo de datos tanto para leer como para escribir. Las operaciones se agrupan en las cuatro acciones básicas:
  • Crear
  • Leer
  • Actualizar
  • Eliminar
Todo se gestiona sobre una sola base de datos y un único modelo.

Ventajas principales

  • Es simple de implementar y de mantener.
  • Funciona muy bien en la mayoría de las aplicaciones.
  • Resulta suficiente cuando las necesidades de lectura y escritura son similares.
Este enfoque es ideal para aplicaciones sencillas o dominios donde no existen grandes diferencias entre cómo se consulta la información y cómo se modifica.

CQRS

CQRS parte de una premisa distinta: separar los modelos de comandos de "escritura" y de consultas de "lectura".
  • Commands (escritura): se centran en las reglas de negocio y el modelo de escritura.
  • Queries (lectura): utilizan un modelo optimizado específicamente para las consultas.
La sincronización entre ambos modelos puede ser en tiempo real o eventual, y se puede implementar con una o dos bases de datos según las necesidades.

Beneficios destacados

  • Permite optimizar lectura y escritura de forma independiente.
  • Ideal para consultas complejas y reglas de negocio estrictas.
  • Ofrece mayor escalabilidad al poder escalar lectura y escritura por separado.

Comparación rápida

Aspecto CRUD tradicional CQRS
Modelo de datos Único para lectura y escritura Separados (comando y consulta)
Base de datos Una sola Una o dos (según necesidad)
Complejidad Baja Mayor
Rendimiento Puede ser suficiente Mejor en escenarios específicos
Escalabilidad Limitada Mayor (lectura y escritura independientes)
Ideal para Aplicaciones simples o con necesidades similares Dominios complejos, consultas avanzadas, reglas de negocio estrictas

Puntos importantes

CQRS no significa necesariamente tener dos bases de datos. Tampoco implica automáticamente Event Sourcing + Kafka + Microservicios. Se puede implementar de forma más sencilla separando solo los modelos de lectura y escritura dentro de la misma aplicación y utilizando la misma base de datos.
La arquitectura debe evolucionar según la necesidad real del sistema, no según las tendencias del momento.