Documentación

Frescura y Repetición

La frescura describe cuán actuales son las proyecciones del daemon de lectura en relación con el registro de confirmaciones. La reproducción es el mecanismo que mantiene las proyecciones sincronizadas.

Problema que este concepto resuelve

En los sistemas basados en eventos, las escrituras y lecturas están separadas:

  • El daemon de escritura compromete eventos de inmediato
  • El daemon de lectura debe procesar esos eventos para actualizar su vista

Esto crea una brecha de frescura: el tiempo entre cuando un commit es reconocido y cuando aparece en las consultas de lectura. Comprender esta brecha es esencial para:

  • Construyendo aplicaciones que necesitan lecturas consistentes
  • Diagnóstico de la aparente “obsolescencia” de los datos
  • Ajuste del rendimiento del sistema

Ideas centrales

Registro de Commits

El registro de commits es la secuencia duradera de lotes de eventos:

  • Solo de anexar: Nuevos lotes se añaden al final
  • Inmutable: Una vez escrito, los lotes no cambian
  • Secuenciado: Cada lote tiene un número de secuencia monótono

El daemon de escritura agrega entradas al registro; el daemon de lectura las sigue.

Proyecciones

Las proyecciones son vistas en memoria del estado:

  • Construido aplicando eventos del registro de commits
  • Optimizado para el rendimiento de consultas
  • Publicado de manera atómica a través de intercambio de instantáneas

Las proyecciones son datos derivados. Si se pierden, se pueden reconstruir a partir del registro de confirmaciones.

Puntos de control

Los puntos de control registran el progreso a través del registro de confirmaciones:

  • Escritura de daemon: Rastrea la última secuencia comprometida
  • Demonio de lectura: Rastrea la última secuencia aplicada

Los puntos de control permiten:

  • Inicio rápido (reanudar desde el punto de control, no desde el principio)
  • Recuperación de fallos (repetir desde el punto de control)
  • Cálculo de frescura (comparar puntos de control)

Metadatos de Frescura

Las respuestas leídas incluyen información de frescura:

{
  "freshness": {
    "checkpoint_seq": 42,
    "commit_log_seq": 45
  }
}
  • checkpoint_seq: La secuencia que ha procesado el daemon de lectura
  • commit_log_seq: La última secuencia en el registro de confirmaciones

La diferencia es el retraso: cuántos commits aún no se han aplicado.

Proceso de Repetición

Cuando el daemon de lectura sigue el registro de confirmaciones:

  1. Obtener el siguiente lote después del punto de control
  2. Aplicar cada evento a través de los configuradores L1
  3. Actualizar punto de control
  4. Publicar nueva instantánea

Los eventos son idempotentes: aplicar el mismo evento dos veces produce el mismo estado. Esto hace que la repetición sea segura para reintentar.

Flujo de Recuperación

Después de un fallo:

  1. Cargar el punto de control desde el disco
  2. Recuperar eventos desde la posición de punto de control
  3. Repetir eventos para reconstruir el estado
  4. Reanudar el bucle de cola normal

Porque los eventos llevan un estado posterior, la reproducción no necesita re-ejecutar la lógica de negocio. Simplemente establece los valores finales.

Cómo se integra en el sistema

Escribir Ruta

Client → Write Daemon → Commit Log
                         ↓
              [checkpoint updated]

El daemon de escritura actualiza su punto de control después de una persistencia exitosa.

Leer Ruta

Commit Log → Read Daemon → Projections → Client
    ↓
[checkpoint updated after apply]

El daemon de lectura publica instantáneas antes de actualizar su punto de control. Esto asegura:

  • Las consultas siempre ven un estado consistente
  • Los fallos no pierden el trabajo aplicado pero no registrado.

Informe de Frescura

El endpoint de salud informa sobre retrasos:

{
  "commit_log": {
    "end_seq": 100,
    "checkpoint_seq": 98,
    "lag": 2
  }
}

Monitore esto para detectar:

  • Funcionamiento normal (retraso cerca de 0)
  • Aumento temporal (picos de latencia que luego se recuperan)
  • Problemas sistemáticos (el retraso crece continuamente)

Invariantes y garantías clave

Consistencia Eventual

Las proyecciones eventualmente reflejarán todos los eventos comprometidos:

  • El daemon de lectura sigue continuamente el registro
  • La latencia puede aumentar durante ráfagas, pero se recupera
  • Ningún evento comprometido es permanentemente invisible

Publicar-antes-del-punto-de-control

Las instantáneas se publican antes de que se actualicen los puntos de control:

  • Las consultas ven datos que están garantizados como aplicados
  • Los fallos no hacen que los datos “desaparezcan”
  • Recuperación de repeticiones desde el último punto seguro

Reproducción Determinista

La reproducción produce un estado idéntico:

  • Los eventos llevan valores post-estados
  • No hay lógica de negocio durante la reproducción
  • Mismos eventos → mismo estado

Seguridad del Punto de Control

Los puntos de control se persisten de manera atómica:

  • No se permiten escrituras parciales de puntos de control
  • La recuperación siempre encuentra un punto de control válido
  • El progreso nunca se pierde entre reinicios

Ver también