Documentación

Modelo de Ejecución

El modelo de tiempo de ejecución define cómo Asset Core procesa los cambios de estado y sirve consultas con garantías deterministas y auditables.

Problema que este concepto resuelve

Los sistemas distribuidos enfrentan una tensión fundamental entre consistencia, disponibilidad y tolerancia a particiones. Los enfoques tradicionales a menudo sacrifican uno para lograr los otros, lo que lleva a:

  • Condiciones de carrera cuando múltiples escritores actualizan el mismo estado
  • Actualizaciones perdidas cuando los cambios concurrentes se sobrescriben entre sí
  • Comportamiento no determinista que dificulta la depuración y la auditoría
  • Protocolos de consenso costosos que añaden latencia y complejidad

Asset Core resuelve estos problemas al adoptar una arquitectura de un solo escritor con almacenamiento de eventos, intercambiando la escalabilidad horizontal de escritura por un determinismo absoluto y simplicidad.

Ideas centrales

Mundo de Escritor Único

Cada mundo tiene exactamente un escritor. Esto elimina:

  • Sobrecarga de coordinación entre escritores
  • Condiciones de carrera en mutaciones de estado
  • La necesidad de bloqueos distribuidos o consenso

El daemon de escritura serializa todos los commits a través de un único pipeline. Si bien esto limita el rendimiento de escritura a lo que un nodo puede manejar, garantiza que cada commit vea una vista consistente del mundo.

Registro de Commits como Fuente de Verdad

Todos los cambios de estado se registran como eventos en un registro de confirmaciones de solo anexado:

  • Los eventos están sellados en lotes antes de la confirmación
  • Los lotes son persistidos de manera duradera antes de que los clientes reciban respuestas de éxito
  • El registro es el documento autoritativo de todo lo que sucedió

Este diseño permite la reproducción determinista: dado la misma secuencia de eventos, cualquier lector reconstruirá el mismo estado.

Proyecciones

Las proyecciones son vistas optimizadas para lectura del estado derivadas del registro de confirmaciones:

  • El daemon monitorea el registro de confirmaciones en busca de nuevos lotes
  • Los eventos se aplican a través de la reproducción para actualizar el estado en memoria
  • Las instantáneas se publican de manera atómica para el servicio de consultas

Las proyecciones son eventualmente consistentes con el registro de confirmaciones. La brecha entre los eventos confirmados y las proyecciones publicadas es el retraso de frescura.

Arquitectura de Tres Capas

La ejecución separa las preocupaciones en tres capas:

CapaResponsabilidadComportamiento
L1 (Almacenamiento)Mutaciones de datos en brutoSin validación, sin eventos
L2 (Operaciones)Lógica de negocioValida precondiciones, emite eventos
L3 (Transacciones)CoordinaciónRegistra deshacer, maneja repetición

Esta separación asegura que:

  • Las operaciones de almacenamiento son rápidas y predecibles
  • Las reglas de negocio se aplican de manera consistente
  • Las transacciones pueden ser revertidas de manera atómica

Cómo se integra en el sistema

El modelo de ejecución da forma a cada aspecto de Asset Core:

Escribir Ruta:

  1. El cliente envía la solicitud de confirmación
  2. El daemon valida y ejecuta operaciones (L2/L3)
  3. Los eventos se sellan y se persisten en el registro de confirmaciones
  4. El cliente recibe éxito con el número de secuencia

Ruta de Lectura:

  1. Leer el registro de commits de los daemon tails
  2. Los eventos se reproducen a través de los setters de L1 (idempotentes)
  3. Las proyecciones se publican a través de un intercambio atómico
  4. Consultas leídas desde la proyección actual

Recuperación:

  1. Cargar punto de control (último estado conocido bueno)
  2. Repetir eventos desde la posición de punto de control
  3. Reanudar la operación normal

Invariantes y garantías clave

Determinismo

Dada la misma secuencia de eventos, la reproducción produce un estado idéntico. Esto requiere:

  • Las operaciones emiten post-state en eventos (no deltas)
  • Replay utiliza L1 setters (sin aritmética, sin validación)
  • No hay dependencias externas durante la reproducción

Idempotencia

Aplicar el mismo evento dos veces no tiene efecto adicional:

  • Los eventos llevan el estado final a establecer
  • La reproducción simplemente sobrescribe con ese estado
  • Seguro para reintentar después de fallos

Atomicidad

Todas las operaciones en un commit tienen éxito o fallan juntas:

  • Los registros L3 deshacen pasos durante la ejecución
  • Las fallas activan el rollback de todos los cambios
  • No se ven commits parciales

Seguridad en caso de fallos

El sistema se recupera correctamente de los fallos:

  • El registro de commits sobrevive a los reinicios
  • Los puntos de control registran el progreso
  • La reproducción reconstruye cualquier estado faltante

Ver también