Qué es la Consistencia Eventual | Diseño de Sistemas
Vložit
- čas přidán 2. 07. 2024
- Un concepto básico del diseño de sistemas (distribuidos) es la consistencia eventual. En este vídeo la explicamos con un ejemplo típico en muchas empresas de software.
→ Curso RabbitMQ: bit.ly/curso-rabbitmq
﹤🍍﹥ Codely
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🔖 Cursos: bit.ly/cursos-codely
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv
Timeline:
00:00 Consistencia Eventual vs Eventual Consistency
01:40 Primeros sistemas distribuidos
04:00 Dependencia entre sistemas distribuidos
04:58 Circuit Breaker
09:52 Solución definitiva - Věda a technologie
Vuestros videos son de los que tengo que ver haciendo varias pausas, con bolígrafo y papel en mano.
En este caso descripción de problemas grandes relacionados con aplicaciones grandes.
Simplemente genial. 😮😮😮
Quien quiera seguir aprendiendo de esto, les recomiendo leer sobre el patrón Inbox/Outbox que se puede implementar en múltiples lenguajes. Esto que comentan en el video es el clásico ejemplo de un flujo de Negocio + Data Science realmente conectado y con en “tiempo real”
Muchas gracias por el detalle del patrón. Buscaré.
Muy buena!
Si un sistema hace un request a otro sistema ya estás rompiendo la arquitectura de eventos. La desventaja que hay es que es bastante más difícil de debuggear , es más costoso porque tenes que mantener SQS y SNS , pero es la mejor forma de abstraerte de sistemas
Que buen video
Tengo una pregunta sobre el escalado. Hay que tener cuidado con la sincronía en base de datos. Si en la tabla de usuarios tenemos los datos del usuario + el total de vídeos, para tener la sincronía y hacer bien la cuenta hay que bloquear la fila para poder hacer los updates bien no? Hay otra alternativa a esto?
Podriais hacer un video de como afecta la consistencia eventual al front end.
Por ejemplo tras añadir un elemento a una lista el frontend redirige a una pagina donde se ven los elementos de la lista pero al solicitar la lista se lee desde una proyección que aun no está actualizada, lo que causa problemas en la experiencia de usuario.
Muy buena! Lo que comentais que un equipo (videos en este caso) tiene que coger un ticket, crear un endpoint para usuarios y mantenerlo solo para este equipo, es lo mismo con los eventos de Dominio no? El coste es mucho menor (emitir un evento vs crear un endpoint), pero sigues teniendo un mierdecilla mas pequeña del lado del equipo que mantiene el evento, no? Un saludo!!!!
Interesante.
Hola, quisiera saber si tienen alguna precio especial en su pagina para estudiantes? o si es el mismo precio para todos, soy de argentina y me gustaría mucho poder pagar sus cursos, aunque desgraciadamente mi familia no puede costear 30euros todos los meses
Yo recomendaria que corten
Pregunta, si en la base de datos de User se necesita guardar mas información de videos, ¿de donde lo obtengo del mismo evento "video_created" o se tiene que ir a buscar al servicio videos?
Eso es una decision de diseño que dependera de tu contexto. Puedes usar event carried state transfer, para enviar toda la info que puedan necesitar los consumidores o pedirles que se suscriban a otros eventos que tengan esa informacion que necesitan para crear su proyeccion. There is no silver bullet, it's all about tradeoffs 😅
Un sistema que funciona con red propia y puede usar todo nativo no necesita que esten porque es un sistema aparte amigo
También se puede actualizar la variable de total_videos_created independientemente del servicio de vídeos, y luego actualizar los datos mediante una tarea en background o un cron que se autoejecute cada x tiempo
Que salgan de sistemas qie no les pertenece
Al final, todo es semántica