Núcleo Event-Driven

Qué es Event-Driven Kernel

El núcleo Event-Driven (EDC) es un «espín» de arquitectura en el que los hechos empresariales se registran y propagan como eventos inmutables, y el resto de la funcionalidad (lectura, integración, analítica, caché, notificaciones) se construye sobre el flujo de estos eventos. El núcleo establece el contrato de eventos, las reglas de entrega y los invariantes de orden/idempotencia, asegurando una conectividad y escalabilidad débiles.

Una idea clave: primero escribir el hecho (núcleo) y luego enriquecerlo y proyectarlo de forma independiente en los modelos deseados. Esto reduce la conectividad y aumenta la resistencia a fallas parciales.

Objetivos y propiedades de EDC

La verdad de los hechos: cada evento es un registro inmutable de «lo que sucedió».
Conectividad débil: los productores no conocen a los consumidores; Extensión del sistema: mediante la adición de suscriptores.
Escala: crecimiento horizontal por lotes/topics, consumidores independientes.
Observabilidad y auditoría: identificadores de extremo a extremo, reproducibilidad, retenciones y reprueba.
Evolución controlada: versiones de circuitos, compatibilidad, deprecation.

Componentes de arquitectura

1. Bus/bróker de eventos: Kafka/NATS/Pulsar/SNS + SQS - canales, lotes, retenciones.
2. Registro de circuitos: JSON Schema/Avro/Protobuf para compatibilidad y evolución.
3. Outbox/contorno CDC: fijación atómica de hechos + publicación sin «doble registro».
4. Proyecciones/lecturas (CQRS): vistas materializadas para consultas rápidas.
5. Sagas/orquestación: coordinación de procesos de larga vida a través de eventos/equipos.
6. Enriquecimiento: topics individuales '.enriched '/' .derived' sin afectar el camino crítico.
7. Observabilidad: rastreo, lógica, métricas por eventos y lagunas.

Modelo de eventos

Tipos

Domain Events: Business Facts ('pago. authorized`, `kyc. approved`).
Eventos de integración: orientados a sistemas externos (estables, lentamente cambiantes).
Cambio de captura de datos (CDC): cambios técnicos de escritura (utilice para migraciones/integraciones).
Audit/Telemetry: Actors Actions, Security, SLA.

Atributos obligatorios (núcleo)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}

Recomendaciones: 'event _ id' es globalmente único, 'partition _ key' establece el orden para la entidad, 'trace _ id' proporciona correlación.

Semántica de entrega e idempotencia

At-least-once (por defecto en muchos corredores): los consumidores están obligados a ser idempotentes.
At-most-once: aceptable sólo para telemetrías secundarias.
Exactly-once: se logra a nivel de flujo y almacenamiento a través de transacciones/llaves/leaks idempotentes (más caro, se necesita una buena razón).

Plantilla de idempotencia del consumidor

Tabla de dedoup por 'event _ id '/' (event_id, consumer_id)' con TTL ≥ retoque topic.
Upsert en lugar de insert; versionar las proyecciones por 'sequence '/' occurred _ at'.
Operaciones dentro de una transacción: la marca «visto» + cambio de estado.

Orden y envío

Orden garantizado dentro del partido.
Seleccione 'partition _ key' para que todos los eventos de la misma entidad agregada caigan en el mismo lote ('user _ id', 'payment _ id').
Evite las «llaves calientes»: hash con sal/sub-llaves si desea distribuir la carga.

Esquemas y evolución

Additive-first: nuevos campos opcionales, prohibición de cambiar tipos/semánticas sin la versión mayor.
Compatibilidad: BACKWARD/FORWARD en el registro de esquemas; CI bloquea los cambios incompatibles.
Nomenclatura: 'domain. action. v{major}` (`payment. authorized. v1`).
Migraciones: publicar pares 'v1' y 'v2' en paralelo, proporcionar doble radiación (dual-write a través de outbox), disparar 'v1' después de la transición.

Outbox и CDC

Outbox (recomendado para servicios transaccionales)

1. En una sola transacción de BD: Guardamos el registro de dominio y el evento en outbox.
2. El pablista de fondo lee outbox, publica en el corredor, marca «enviado».
3. Garantías: no hay «pérdida» de hecho en caídas, no hay resincronización.

CDC (Change Data Capture)

Adecuado para sistemas/migraciones existentes; fuente - registro de replicación de DB.
Requiere filtrar/recodificar en eventos de dominio (no transmita tablas «crudas» hacia afuera).

CQRS y proyecciones

Los comandos cambian de estado (a menudo sincronizado), los eventos forman proyecciones (asíncronas).
Las proyecciones están diseñadas para consultas (búsquedas, listas, informes), actualizadas por los suscriptores.
La resincronización temporal es la norma: mostrar UX constante («los datos se actualizarán en unos segundos»).

Sagas: coordinación de procesos

Orquestación: un coordinador envía comandos y espera eventos.
Coreografía: los participantes responden a los acontecimientos del otro (más simples, pero requieren disciplina en los contratos).
Reglas: compensación clara y tiempos de espera, pasos repetibles, manejadores idempotentes.

Observ

Trace/Span: busque 'trace _ id '/' span _ id' a través de los encabezados cuando se generan eventos.
Métricas: valor de los consumidores, tasa de publicación/consumo, tasa de dead-letter, proporción de deduplicaciones.
DLQ/parking lot: mensajes fallidos - en un topic separado con alert; asegúrese de volver a trabajar.

Seguridad

Clasificación de datos: el núcleo contiene sólo el mínimo necesario de PII/findans (modelo de pirámide inversa), los detalles están en enriquecimiento.
Firma/hash de atributos críticos, control de integridad.
Encriptación in-flight y at-nat, seccionamiento de derechos por tema/consumer (IAM/ACL).
Políticas de retenciones y derechos al olvido: claramente definidas para cada topic.

Rendimiento y sostenibilidad

Backpressure: los consumidores tienen limitaciones de competencia, los corredores tienen cuotas/límites.
Procesamiento de batch y compresión: agrupe los registros para reducir los gastos generales.
Retrés con jitter y DLQ en lugar de intentos interminables.
Rebalance-durabilidad: guarde los offsets transaccional/externamente, acelere el inicio frío con los snapshots.

Plantillas de eventos típicas

Motor

`payment. initiated. v1` → `payment. authorized. v1` → `payment. captured. v1` → `payment. settled. v1`

Rechazos: 'pago. declined. v1`, `payment. refunded. v1`

Lote: 'payment _ id'

SLA: valor del núcleo ≤ 2s p95; la idempotencia de los consumidores es obligatoria.

`kyc. started. v1` → `kyc. document. received. v1` → `kyc. approved. v1`/`kyc. rejected. v1`

PII - mínimo; detalles del documento - en 'kyc. enriched. v1 'con acceso restringido.

Auditoría/seguridad

`audit. recorded. v1 'con los atributos' actor ',' subject ',' action ',' occurred _ at ',' trace _ id '.
Retén/archivado continuo; integridad mejorada (almacenamiento WORM).

Antipattern

Fat Event: payload's sobrecargados sin necesidad, fugas PII.
Hidden RPC a través de eventos: esperando respuestas sincrónicas «aquí y ahora».
CDC crudos hacia afuera: estrecha conectividad con el circuito DB.
No hay idempotencia en los consumidores: las tomas producen efectos secundarios dobles.
Un topic común «a todo»: conflicto de intereses, orden problemático, evolución compleja.

Implementación paso a paso de EDC

1. Mapeo de dominio: resalte agregados clave y ciclos de vida.
2. Directorio de eventos: nombres, significados, invariantes, campos obligatorios.
3. Diagramas y registro: seleccione el formato, habilite las reglas de compatibilidad.
4. Outbox/CDC: para cada productor, determine el mecanismo de publicación de los hechos.
5. Partición: seleccione las claves y evalúe las teclas calientes/sobrescritura.
6. Idempotencia: patrón de dedup + transaccionalidad de los consumidores.
7. Proyecciones: defina modelos materializados y actualizaciones SLA.
8. Observabilidad: rastreo, lags, DLQ, alertas.
9. Seguridad/PII: clasificación de datos, cifrado, ACL.
10. Hyde on evolution: version policy, deprechate, dual-write para migraciones.

Lista de verificación de producción

• Cada evento tiene 'event _ id', 'trace _ id', 'occurred _ at', 'partition _ key'.
• Los esquemas del registro están habilitados para las comprobaciones de compatibilidad.
• La idempotencia del consumidor ha sido implementada y probada.
• DLQ/parking lot y alertas configuradas para errores de publicación/consumo.
• Las proyecciones se vuelven a crear a partir de un registro (replay) con un tiempo aceptable.
• Acceso restringido a PII; payload's mínimos en el núcleo.
• Los SLA por lags/entrega son medidos y visibles en los dashboards.
• Hay un plan para migrar versiones de eventos y ventanas de deprechate.

FAQ

¿En qué se diferencia EDC de «solo un bus»?
El núcleo no es sólo un corredor, sino también un contrato de eventos, reglas de orden/idempotencia, procesos de evolución y observabilidad.

¿Se puede construir sólo en CDC?
Los CDC son adecuados para integraciones/migraciones, pero los eventos de dominio expresan más claramente el significado y experimentan cambios más estables en la DB.

¿Qué hay de coherente?
Aceptamos consistencia eventual y diseñamos UX/procesos bajo ella (indicadores de actualización, retraídas, compensación).

¿Cuándo necesitas exactly-once?
Rara vez: cuando la duplicación es estrictamente inaceptable e imposible de compensar. Más a menudo, la idempotencia al-least-once + es suficiente.

El núcleo Event-Driven transforma el flujo de hechos empresariales en la base confiable del sistema. Los contratos claros de eventos, la disciplina de entrega y la observabilidad dan escalabilidad, estabilidad y velocidad de evolución - sin conexiones sincrónicas frágiles y una «tormenta» de regresiones en los cambios.