Event sourcing vs bases relacionales
Clase 16 de 43 • Curso Profesional de Arquitectura de Software
Contenido del curso
Atributos de calidad
- 2

Qué son los atributos de calidad en software
01:49 min - 3

Cómo medir idoneidad funcional en software
02:52 min - 4

Qué es eficiencia de ejecución en software
04:14 min - 5

Cómo medir interoperabilidad y coexistencia
03:49 min - 6

Qué es la usabilidad y sus 6 dimensiones
08:14 min - 7

Cómo medir confiabilidad en software
05:38 min - 8

Los 5 pilares de seguridad en software
04:01 min - 9

Cómo garantizar mantenibilidad con tests
06:27 min - 10

Adaptabilidad vs capacidad de instalación vs reemplazo
02:48 min - 11

Tensiones entre atributos de calidad de software
04:04 min - 12

Atributos de calidad según fase de empresa
07:00 min
Patrones de arquitectura
- 13

Qué es un patrón de arquitectura
02:50 min - 14

Modelo vista controlador: cómo separar responsabilidades
05:37 min - 15

Arquitectura en capas: controller, servicio y repositorio
03:14 min - 16

Event sourcing vs bases relacionales
Viendo ahora - 17

Qué es la arquitectura microkernel
01:52 min - 18

Arquitectura Comparte Nada con Map Reduce
02:29 min - 19

Patrón de microservicios: cuándo y cómo
03:57 min - 20

Qué es CQRS y cómo separa lectura de escritura
03:24 min - 21

Arquitectura hexagonal: puertos y adaptadores
04:10 min - 22

Qué son los contextos delimitados en DDD
05:34 min - 23

Cómo combinar patrones de arquitectura
09:22 min - 24

Evolución de patrones desde monolito a microservicios
07:58 min
Diseño de una arquitectura
- 25

Cómo traducir requerimientos en decisiones arquitectónicas
02:18 min - 26

Conectores en arquitectura: tipos y cuándo usarlos
06:18 min - 27

Llamadas asíncronas vs síncronas vs cliente-servidor
03:05 min - 28

Conector enrutador vs difusión: Twitter
01:55 min - 29

Conectores cola, repositorio y pub/sub
03:52 min - 30

Framework de diseño orientado a atributos
01:55 min - 31

Cómo detectar fallas y reparar sistemas
05:59 min - 32

Cómo recuperar y prevenir fallas en sistemas
04:09 min - 33

Tácticas para confinar modificaciones
06:15 min - 34

Cómo prevenir efectos dominó en software
12:17 min - 35

Tácticas para controlar eficiencia de ejecución
09:14 min - 36

Cómo detectar, resistir y recuperarse de ataques
09:02 min - 37

Cómo probar que el software funciona correctamente
05:14 min - 38

Cómo controlar la usabilidad con tácticas
08:20 min - 39

Cómo validar arquitectura con ATAM y métricas
06:34 min - 40

Evolución de arquitectura: startup a gran escala
10:30 min
Modelado y documentación de arquitectura
Comprende con claridad cómo la arquitectura orientada a eventos conecta componentes mediante un bus de eventos, reduce acoplamiento entre microservicios y habilita escalabilidad. Aquí verás cómo operan productores y consumidores, por qué aparece la consistencia eventual, qué complica las pruebas end-to-end, y cuándo conviene usar event sourcing con un log de eventos para auditoría y recuperación.
¿Qué es la arquitectura orientada a eventos y cómo conecta microservicios?
En un enfoque event driven, los componentes no se comunican directamente: el bus de eventos es el medio principal. Con el patrón publish and subscribe, cada componente publica eventos y otros se suscriben para reaccionar sin acoplamiento. Esto favorece despliegues y mantenimiento en arquitecturas de microservicios, evitando dependencias rígidas.
¿Cómo operan productores y consumidores de eventos?
- Una API actúa como productora y consumidora de eventos.
- Ante una escritura, publica un evento para registrar que “algo” debe persistirse.
- Módulos como ventas o clientes consumen ese evento y actualizan sus bases.
- Un proceso de importación de archivo grande publica contenidos como eventos.
- Cada servicio suscrito consume lo que le corresponde.
¿Qué habilidades clave se ponen en práctica?
- Modelar productores y consumidores claros.
- Diseñar un bus de eventos como canal único de comunicación.
- Definir suscripciones por tipo de evento.
- Mantener bajo acoplamiento entre módulos.
- Pensar despliegue y mantenimiento independientes.
¿Qué retos plantea la consistencia eventual y las pruebas end-to-end?
Un desafío es validar si una acción produjo el resultado esperado. Con consistencia eventual, una escritura no es inmediatamente visible: el sistema no garantiza disponibilidad hasta que el evento se distribuya donde corresponde. Además, las pruebas end-to-end son más complejas porque deben orquestar el bus y los múltiples módulos.
¿Qué implica la consistencia eventual para microservicios?
- La escritura no asegura visibilidad inmediata.
- Se requiere propagar el evento a todas las partes interesadas.
- Las lecturas pueden transitoriamente mostrar estados desactualizados.
- El diseño debe tolerar demoras y reacciones asíncronas.
¿Cómo abordar pruebas end-to-end con bus de eventos?
- Integrar el bus en el entorno de prueba.
- Conectar eventos con los módulos involucrados.
- Orquestar flujos completos de publicación y consumo.
- Asumir mayor complejidad en escenarios integrales.
¿Cómo funciona el event sourcing y cuándo conviene usarlo?
El event sourcing propone almacenar solo los eventos relevantes, no el “estado actual” como tablas relacionales. Los eventos se leen de forma secuencial para reconstruir el estado. Con un histórico de eventos, se puede conocer el estado presente y el de cualquier instante del ciclo de vida. Esto es potente para auditoría, debugging y recuperación ante ataques, atributos de calidad valiosos. Presenta retos: la lectura del estado se vuelve más costosa a medida que crecen los eventos, por lo que se aplican patrones para calcular estados intermedios y para construir vistas que respondan rápido a necesidades como modelos específicos u estados agregados para reportes.
¿Cómo aplica en una app bancaria con transferencias y depósitos?
- Guardar cada depósito y extracción como evento.
- Leer el log secuencialmente para calcular el saldo.
- Evaluar un nuevo evento y validar si deja la cuenta en números rojos.
- Aceptar o rechazar operaciones según el estado derivado de eventos.
¿Qué consideraciones de capacidad y patrones de diseño importan?
- Guardar todos los eventos exige recursos y capacidad.
- Usar patrones para estados intermedios y acelerar cálculos de estado.
- Derivar diferentes vistas desde eventos: por objeto, por reporte o por presentación de datos.
- Evaluar beneficios y consecuencias del patrón según el escenario.
- Decidir si event sourcing es adecuado antes de adoptarlo.
¿Te gustaría compartir un caso donde el bus de eventos te ayudó a desacoplar servicios o donde event sourcing facilitó auditoría? Comenta tu experiencia y dudas.