GuíaBásico
Guía de Arquitectura Dirigida por Eventos
Aprende a construir sistemas que se comunican por eventos en vez de por llamadas directas: cuándo un evento le gana a una llamada síncrona, cómo funciona un broker, cómo consumir eventos de forma idempotente, cómo publicarlos de forma confiable con el patrón outbox, y los patrones grandes que habilita —event sourcing, CQRS, sagas—. Trabajas sobre un solo caso de principio a fin: Mercado, cuyo checkout hoy es una cadena frágil de llamadas síncronas (si `notifications` cae, el pedido falla), y que vas a convertir en un flujo dirigido por eventos donde `orders` emite `OrderPlaced` y varios servicios reaccionan de forma desacoplada. Todo se simula y se ejecuta en Python con un broker en memoria: vas a medir cómo la entrega at-least-once produce duplicados y cómo un consumidor idempotente los neutraliza, simular un crash que expone el dual-write problem y ver cómo el outbox lo resuelve, reconstruir el estado de un `Order` reproduciendo su log de eventos, y ejecutar una saga con compensación. Al terminar sabes qué gana y qué paga un sistema dirigido por eventos frente a uno síncrono.
- 64
- lecciones
- 8
- módulos
- Inglés · Español
- disponible en
- Sí
- certificado
- Gratis
- acceso
Resultados
Lo que vas a poder hacer
- Distinguir evento de comando, y entender el desacople temporal que habilita el patrón pub/sub
- Comprender el broker: cola vs. topic, offset, grupos de consumidores, y por qué la entrega es at-least-once (nunca exactly-once)
- Construir consumidores idempotentes que deduplican por `event_id`, y manejar el orden cuando no está garantizado
- Resolver el dual-write problem con el patrón outbox: publicar un evento de forma confiable en la misma transacción que el dato
- Aplicar event sourcing: guardar el log de eventos como fuente de verdad y reconstruir el estado por replay
- Aplicar CQRS: separar el modelo de escritura del de lectura y entender la consistencia eventual del read model
- Diseñar sagas para transacciones de negocio que cruzan varios servicios, con acciones compensatorias cuando un paso falla
- Convertir de punta a punta un flujo síncrono frágil en uno dirigido por eventos, con idempotencia, outbox y saga ejecutados y medidos
Antes de empezar
Qué necesitas traer
Es para ti si...
- Backend devs con un flujo síncrono frágil (una llamada cae y todo el proceso falla) que quieren desacoplarlo
- Devs que ya usan una cola o un broker mensajería pero no aplican idempotencia ni manejan duplicados con criterio
- Cualquiera que necesite entender event sourcing, CQRS o sagas antes de decidir si su sistema los necesita
- Equipos evaluando mover parte de su arquitectura de llamadas síncronas a eventos, y quieren medir el tradeoff, no asumirlo
Requisitos y materiales
- Python básico (los brokers y las simulaciones de esta guía corren en Python, sin Kafka ni RabbitMQ reales)
- Conocimientos generales de bases de datos y transacciones
- No se requiere experiencia previa con mensajería, colas ni sistemas distribuidos
Contenido
El temario, módulo por módulo
Abre cualquiera para ver sus lecciones.
- 1. Presentación del módulo: la deuda de at-least-once
- 2. Qué es un consumidor idempotente
- 3. Deduplicar por event_id
- 4. Dedup atómico e idempotencia natural
- 5. Por qué el orden no está garantizado
- 6. La clave de partición
- 7. Manejar eventos fuera de orden
- 8. Proyecto: construye un consumidor idempotente y ordenado
- 1. Presentación del módulo: guardar los hechos, no el resultado
- 2. Guardar los eventos, no el estado
- 3. El `Order` como la suma de sus eventos
- 4. Reconstruir el estado por replay
- 5. El log como fuente de verdad
- 6. Snapshots
- 7. Cuándo usar event sourcing (y cuándo es sobre-ingeniería)
- 8. Proyecto: convertir el `Order` de Mercado a event sourcing
- 1. Presentación del módulo: separar lo que escribe de lo que lee
- 2. Comando y query: dos operaciones, dos modelos
- 3. La proyección y el read model
- 4. Consistencia eventual: el read model va atrás
- 5. Un log, muchos read models
- 6. Leer solo del read model (y reconstruirlo)
- 7. Cuándo usar CQRS (y cuándo sobra)
- 8. Proyecto: partir el flujo de pedidos de Mercado en escritura y lectura
- 1. Presentación del módulo: la transacción que cruza servicios
- 2. El problema de la transacción que cruza servicios
- 3. Por qué no two-phase commit
- 4. La saga y las acciones compensatorias
- 5. Coreografía contra orquestación
- 6. El aislamiento perdido de las sagas
- 7. Compensatable, pivote y retriable
- 8. Proyecto: una saga para el checkout de Mercado
- Presentación del módulo: el recorrido de vuelta, con el sistema completo corriendo
- 2. Modelar los eventos del pedido
- 3. Publicar los eventos del pedido con el outbox
- 4. Consumidores idempotentes y desacoplados
- 5. La saga del checkout con compensación
- 6. Medir síncrono contra dirigido por eventos
- 7. El registro de la decisión
- Proyecto: vuelve dirigido por eventos el flujo de pedidos de Mercado
Dudas frecuentes
Lo que suele preguntarse
Sin límite. Es una guía gratuita: entras cuando quieras, las veces que quieras.
No. Los módulos están ordenados de menos a más, pero puedes saltar al que necesites. Tu progreso se guarda por lección.
Lo que haga falta está en «Qué necesitas traer», arriba. Si no aparece nada ahí, puedes empezar desde cero.
En el grupo de WhatsApp del Club, y cada quince días hay un live con un instructor donde se resuelven dudas en vivo.
Sí. Al terminar todas las lecciones se emite automáticamente, con un código verificable que puedes compartir en LinkedIn.
Empieza cuando quieras
Lo que dicen los estudiantes
Estas reseñas son de estudiantes inscritos que completaron al menos el 50% del curso. Moderamos las reseñas solo por motivos de contenido (spam, lenguaje ofensivo, datos personales), nunca por ser críticas o negativas.
Aún no hay reseñas aprobadas.
¡Sé el primero en compartir tu experiencia!