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. 😮😮😮
@decimodanlive8 ай бұрын
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”
@Albertus_4008 ай бұрын
Muchas gracias por el detalle del patrón. Buscaré.
@Jefferson40263 ай бұрын
Eventos implementados por base de datos vaya
@decimodanlive3 ай бұрын
@@Jefferson4026 no es tan simple como eso, sobretodo del lado de los consumidores (sobretodo si hay varios en el mismo proyecto)
@rafaelfurtado7958 ай бұрын
Muy buena!
@pmareke8 ай бұрын
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!!!!
@MB-hj1bc8 ай бұрын
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.
@nikolas97ns8 ай бұрын
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?
@PhosphorusMoscu-code8 ай бұрын
Que buen video
@Inbarreto8 ай бұрын
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
@carlosdavila49998 ай бұрын
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?
@RzManhunt8 ай бұрын
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 😅
@rodrigovazquez2598 ай бұрын
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
@gstevenb13724 ай бұрын
.
@willianmonoga55275 ай бұрын
Un buen nombre sería "Finalmente Consistente"
@alekvga8 ай бұрын
Interesante.
@victorgarcia35268 ай бұрын
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
@MarcosAntonioBustos6 ай бұрын
Yo recomendaria que corten
@MarcosAntonioBustos6 ай бұрын
Un sistema que funciona con red propia y puede usar todo nativo no necesita que esten porque es un sistema aparte amigo