CQRS: Command Query Responsibility Segregation
Clase 3 de 22 • Curso de Go Avanzado: Arquitectura de Eventos y CQRS
Contenido del curso
Sebastián Ospino
student•
hace 4 años
Dainer Acosta
student•
hace 4 años
Clase 3 de 22 • Curso de Go Avanzado: Arquitectura de Eventos y CQRS
Contenido del curso
Sebastián Ospino
Dainer Acosta
Jeison Triana
José Antonio De La Paz Fonseca
Cristhian Arboleda
Neo TRAN
Helmer Barcos
Helmer Barcos
Helmer Barcos
La tarea que se le asignó a NGINX no podría ser ejecutada por una API Gateway?
si, sin ningún problema
hay algo que no entiendo y es que si hay un evento para la lectura y otro para la escritura puedo inferir que son dos bds diferentes que ahora mi duda es como se puede controlar eso para mantener la bd de escritura sincronizada?
Por el mismo sistema de eventos de publicador suscriptor de la clase pasada, aunque también se le añade algo de lógica para la sincronización entre evento de lectura y de escritura
¿Por qué el servicio de Query debe consultar los criterios de busqueda en Elastic y luego ir a buscar en la base de datos? Importante: Nunca he usado Elastic
Si yo quisiera que algunos servicios estuvieran protegidos, que el usuario tenga que estar autenticado.
¿Lo tendría que validar NGINX llamando a algún servicio auth o desde cada microservicios usar el manejo de colas para comunicarse con auth por eventos y verificar al usuario?
Si no estoy mal hay diferentes estrategias:
Durante dos semanas tuve una pregunta: ¿los datos estarán en dos lugares a la vez?
La respuesta corta es: ¡sí! De hecho, eso es algo deseado en este tipo de diseño. Pero, lamentablemente, este tema no se abordó en profundidad en el curso.
La respuesta larga se puede consultar en este enlace: 🔗
Básicamente, se entiende que el modelo de lectura y el modelo de escritura enfrentarán retos distintos con el tiempo. Por eso, se necesita una estrategia separada para cada uno y, al mismo tiempo, mantener los datos sincronizados.
Lo que aún me preocupa son los casos en que los eventos fallen o no puedan ser procesados, ya que eso significaría que el modelo de lectura quedaría desactualizado.
Luego de hacer una investigación exhaustiva, encontré que la forma en la que se abordó este curso está hoy en día deprecada.
La recomendación actual es usar NATS JetStream (es decir, la imagen de Docker nats, no nats-streaming), la cual ademas resuelve los problemas relacionados a la entrega de los mensajes y la desconexión de alguna cliente.
Además, la nueva API de JetStream simplifica muchas de las tareas que antes debíamos manejar manualmente con channels. La nueva forma de trabajar se resume en:
PublishAsync.📺 Playlist oficial de NATS JetStream:
📚 Más documentación: