Patrón CQRS
El patrón de división de responsabilidad de consulta de comando (CQRS) separa la mutación de datos, o la parte de comando de un sistema, de la parte de consulta. Puede usar el patrón CQRS para separar las actualizaciones de las consultas si tienen requisitos diferentes de rendimiento, latencia o coherencia. El patrón CQRS divide la aplicación en dos partes: la parte de comandos y la parte de consulta, tal como se muestra en el diagrama siguiente. El lado de comandos gestiona create, update y delete solicita. El lado de la consulta ejecuta la query parte mediante las réplicas de lectura.
El diagrama muestra el proceso siguiente:
-
La empresa interactúa con la aplicación mediante el envío de comandos a través de una API. Los comandos son acciones como crear, actualizar o eliminar datos.
-
La aplicación procesa el comando entrante desde el lado de los comandos. Esto implica validar, autorizar y ejecutar la operación.
-
La aplicación conserva los datos del comando en la base de datos de escritura (comandos).
-
Una vez que el comando se encuentra almacenado en la base de datos de escritura, se activan eventos para actualizar los datos de la base de datos de lectura (consulta).
-
La base de datos de lectura (consulta) procesa y conserva los datos. Las bases de datos de lectura están diseñadas para optimizarse para requisitos de consulta específicos.
-
La empresa interactúa con las API de lectura para enviar consultas a la parte de consultas de la aplicación.
-
La aplicación procesa la consulta entrante en el lado de la consulta y recupera los datos de la base de datos de lectura.
Se puede implementar el patrón CQRS mediante varias combinaciones de bases de datos, entre las que se incluyen:
-
Uso de bases de datos del sistema de administración de bases de datos relacionales (RDBMS) tanto para el lado del comando como para el de la consulta. Las operaciones de escritura van a la base de datos principal y las operaciones de lectura se pueden enrutar a réplicas de lectura. Ejemplo: Réplicas de lectura de Amazon RDS
-
Uso de una base de datos RDBMS para el lado de comandos y una base de datos NoSQL para el lado de consultas. Ejemplo: Modernice las bases de datos antiguas mediante el abastecimiento de eventos y el CQRS con AWS DMS
-
Uso de bases de datos NoSQL tanto para el lado del comando como para el de la consulta. Ejemplo: Creación de un almacén de eventos CQRS con Amazon DynamoDB
-
Uso de una base de datos NoSQL para el lado de comandos y una base de datos RDBMS para el lado de consultas, tal como se plantea en el ejemplo siguiente.
En la siguiente ilustración, se utiliza un banco de datos NoSQL, como DynamoDB, para optimizar el rendimiento de escritura y proporcionar funciones de consulta flexibles. Esto permite una alta escalabilidad de escritura en cargas de trabajo que tienen patrones de acceso bien definidos al agregar datos. Una base de datos relacional, como Amazon Aurora, proporciona una funcionalidad de consulta compleja. Una transmisión de DynamoDB envía datos a una función de Lambda que actualiza la tabla Aurora.
La implementación del patrón CQRS con DynamoDB y Aurora ofrece estas ventajas clave:
-
DynamoDB es una base de datos NoSQL totalmente administrada que puede gestionar operaciones de escritura de gran volumen, y Aurora ofrece una alta escalabilidad de lectura para consultas complejas en el lado de las consultas.
-
DynamoDB proporciona acceso a los datos con baja latencia y alto rendimiento, lo que lo hace ideal para gestionar operaciones de comando y actualización, y el rendimiento de Aurora se puede refinar y optimizar para consultas complejas.
-
Tanto DynamoDB como Aurora ofrecen opciones sin servidor, lo que permite a su empresa pagar los recursos únicamente en función del uso.
-
DynamoDB y Aurora son servicios totalmente administrados, lo que reduce la carga operativa que supone la administración de bases de datos, copias de seguridad y escalabilidad.
Debería considerar la posibilidad de utilizar este patrón CQRS si:
-
Ha implementado el patrón de base de datos por servicio y desea unir datos de varios microservicios.
-
Sus cargas de trabajo de lectura y escritura tienen requisitos distintos de escalado, latencia y coherencia.
-
La coherencia eventual es aceptable para las consultas de lectura.
importante
El patrón CQRS suele dar como resultado una coherencia final entre los almacenes de datos.