FASE 5 – EVENTOS, CONSISTENCIA Y ARQUITECTURA
ORIENTADA A EVENTOS
Guía Brutal Enterprise – Event-Driven Architecture + Consistencia
Distribuida
Aplicable a CORE-PLATFORM | IAM-SERVICE | AI-SERVICE
INTRODUCCIÓN ESTRUCTURAL A LA FASE 5
En sistemas enterprise reales, la escalabilidad no se logra únicamente con más
servidores. Se logra desacoplando procesos mediante eventos y diseñando
correctamente la consistencia.
La Fase 5 define cómo el sistema se comporta cuando: - Múltiples módulos interactúan. -
Existen múltiples instancias ejecutándose. - Se procesan miles o millones de eventos. -
CORE, IAM y AI deben coordinarse sin acoplamiento directo.
Aquí dejamos de pensar en transacciones locales y comenzamos a pensar en
consistencia distribuida.
1. DOMAIN EVENTS COMO PRIMERA CLASE DEL
MODELO
Un Domain Event representa algo significativo que ya ocurrió dentro del dominio.
Debe cumplir: - Ser inmutable. - Estar en pasado. - Tener significado de negocio.
Ejemplo (EduPredict AI): NotaRegistrada RiesgoRecalculado AlertaGenerada
Qué deben documentar
Para cada evento: - Nombre. - Aggregate que lo dispara. - Datos mínimos incluidos. -
Justificación de su existencia.
Ejemplo formal: Evento: NotaRegistrada Aggregate: Estudiante Datos: estudianteId,
nota, fecha, tenantId Justificación: Permite recalcular promedio y disparar análisis
predictivo.
2. EVENTOS INTERNOS VS EVENTOS DE
INTEGRACIÓN
Deben diferenciar:
Domain Event (interno al bounded context). Integration Event (publicado para otros
contextos o servicios).
Ejemplo: NotaRegistrada (interno). NotaRegistradaIntegrationEvent (publicado para AI-
SERVICE).
Error común: Publicar directamente Domain Events fuera del contexto.
Se recomienda mapear eventos internos a eventos de integración.
3. CONSISTENCIA FUERTE VS EVENTUAL –
PROFUNDIZACIÓN
En arquitectura distribuida:
Consistencia fuerte = transacción local atómica. Consistencia eventual = coherencia
alcanzada mediante eventos.
Ejemplo: RegistrarNota → fuerte. Recalcular riesgo → eventual. Enviar notificación →
eventual.
Deben documentar: - Qué procesos requieren atomicidad. - Qué procesos pueden tolerar
latencia.
Justificación obligatoria para cada caso.
4. OUTBOX PATTERN
En sistemas distribuidos, publicar eventos directamente después de guardar datos
puede generar inconsistencias.
El Outbox Pattern asegura: - Persistencia del evento en la misma transacción. -
Publicación posterior segura.
Deben documentar: - Qué eventos críticos usan outbox. - Cómo se procesan. - Qué
ocurre si falla la publicación.
Sin outbox, hay riesgo de pérdida de eventos.
5. IDEMPOTENCIA
En sistemas distribuidos, un evento puede procesarse más de una vez.
Deben definir: - Cómo evitar duplicidad de efectos. - Cómo identificar eventos únicos.
Ejemplo: Evento AlertaGenerada con identificador único. Si se procesa dos veces, no
debe enviar dos notificaciones.
6. ORDENAMIENTO DE EVENTOS
En escenarios complejos, el orden importa.
Ejemplo: NotaRegistrada antes de RiesgoRecalculado.
Deben documentar: - Si el orden es crítico. - Cómo se garantiza.
7. EVENT-DRIVEN ENTRE CORE, IAM Y AI
Deben documentar:
CORE publica: UsuarioCreado. TenantRegistrado.
IAM publica: RolAsignado. PermisoRevocado.
Vertical publica: NotaRegistrada.
AI consume: NotaRegistradaIntegrationEvent.
La comunicación debe ser asincrónica cuando no se requiere respuesta inmediata.
8. SAGAS Y PROCESOS DE LARGA DURACIÓN
Cuando una operación involucra múltiples pasos distribuidos, se usa Saga.
Ejemplo: RegistrarUniversidad → CrearTenant → CrearAdmin → AsignarRoles →
ActivarModeloBase.
Deben documentar: - Pasos. - Eventos intermedios. - Mecanismo de compensación.
9. CONCURRENCIA DISTRIBUIDA
En entornos con múltiples instancias:
Deben documentar: - Uso de versionado optimista. - Estrategia ante conflictos. - Qué
operaciones pueden colisionar.
Ejemplo: Dos procesos recalculando riesgo simultáneamente.
10. ESCALABILIDAD ORIENTADA A EVENTOS
Deben proyectar: - Volumen de eventos por día. - Consumo por AI. - Crecimiento por
tenant.
La arquitectura debe soportar procesamiento paralelo.
11. OBSERVABILIDAD Y TRAZABILIDAD
En sistemas event-driven se requiere:
CorrelationId.
TenantId en cada evento.
Logs estructurados.
Sin trazabilidad, el sistema es inoperable en producción.
12. ANTI-PATRONES CRÍTICOS
Publicar eventos sin transacción segura.
No versionar eventos.
Hacer llamadas síncronas innecesarias entre servicios.
Acoplar servicios mediante consultas directas.
Cada uno debe explicarse con consecuencias reales.
CHECKLIST ENTERPRISE FASE 5
✓ Domain Events definidos correctamente. ✓ Diferenciación entre eventos internos e
integración. ✓ Decisiones de consistencia justificadas. ✓ Outbox documentado. ✓
Idempotencia garantizada. ✓ Estrategia de ordenamiento definida. ✓ Sagas
documentadas si existen. ✓ Concurrencia distribuida considerada. ✓ Observabilidad
definida.
CIERRE ESTRUCTURAL
Si esta fase está bien diseñada:
El sistema será escalable.
CORE, IAM y AI estarán desacoplados.
La evolución será sostenible.
El procesamiento distribuido será confiable.
Si está mal diseñada:
Habrá pérdida de eventos.
Inconsistencias distribuidas.
Acoplamiento excesivo.
Fallos difíciles de diagnosticar.
En arquitectura de grandes ligas, la arquitectura orientada a eventos no es opcional
cuando el sistema crece. Es la única forma de mantener coherencia y escalabilidad.