Jeison Triana
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?
José Antonio De La Paz Fonseca
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
Helmer Barcos
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.
Helmer Barcos
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:
Ivan Sabido
igual existen patrones que ayudan a resolver los problemas que se suelen dar en sistemas distribuidos por ejemplo el Transactional Outbox Pattern, Sagas, Circuit Breaker, Dead letter queue, etc. En el caso que planteas de si el evento falla, lo volvería a encolar y se reintenta por lo que tambien debes tener en cuenta la idempotencia. Si aún así sigue fallando el evento entonces se podría mandar a una Dead Letter Queue (DLQ). En el caso de que el command al guardar en la bd e intentar publicar el evento éste falle, entonces debes tener en cuenta que todo debe estar en una transacción así lo que se escribió en la bd se haría un rollback.
Elias Amado
osea en esta caso NGINX me esta trabajando haciendo las veces de cola pero es solo para el ejemplo verdad? En casos reales si se require desacoplar procesamiento si debemos tener una cola si o si.
Neo TRAN
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?
Helmer Barcos
Si no estoy mal hay diferentes estrategias: