Arxi Decision Gate Asset Core
Docs
Documentació d'Asset Core

Documentació del motor d'estat del món determinista i referències de l'API.

Decision Gate docs

Frescura i Repetició

La frescor descriu com d’actuals són les projeccions del daemon de lectura en relació amb el registre de compromisos. La reproducció és el mecanisme que manté les projeccions sincronitzades. Entendre ambdós és essencial per operar Asset Core a gran escala sense sorpreses d’obsolescència.

Problema que resol aquest concepte

En sistemes basats en esdeveniments, les escriptures i les lectures estan separades:

  • El daemon d’escriptura compromet esdeveniments immediatament
  • El daemon de lectura ha de processar aquests esdeveniments per actualitzar la seva vista

Això crea un bretxa de frescor: el temps entre quan un compromís és reconegut i quan apareix en les consultes de lectura. Entendre aquesta bretxa és essencial per:

  • Construint aplicacions que necessiten lectures consistents
  • Diagnosticar l’aparent “desactualització” de dades
  • Ajustament del rendiment del sistema

Idees principals

Commit Log

El registre de compromisos és la seqüència d’agrupacions d’esdeveniments només d’append. És l’única font utilitzada per reconstruir projeccions, per tant, defineix la línia de temps autoritzada. La durabilitat depèn del backend: els registres en memòria són ràpids i descartables, mentre que els registres en fitxers/segmentats persisteixen a través de reinicis. Aquest disseny (tractat a Runtime Model) és el que fa possibles les garanties d’AssetCore.

  • Només afegir: Nous lots s’afegeixen al final (sense actualitzacions in situ, sense suprimir)
  • Immutable: Un cop escrits, els lots no canvien (no es poden modificar ni reorganitzar)
  • Seqüenciat: Cada lot té un número de seqüència monotònic (ordenació total de tots els esdeveniments)

El daemon d’escriptura afegeix al registre; el daemon de lectura el segueix. Aquesta separació és crítica: el daemon d’escriptura mai bloqueja el rendiment de lectura, i el daemon de lectura pot quedar enrere sense afectar el rendiment d’escriptura. El que guanyeu: escalabilitat d’escriptura i lectura de manera independent, recuperació de fallades quan s’utilitza un backend de registre durable, depuració forense reproduint fins a qualsevol punt. El que renuncieu: les lectures són eventualment consistents, no immediatament consistents—sempre hi ha algun retard.

Projeccions

Les projeccions són vistes en memòria de l’estat. Estan optimitzades per a consultes i sempre es poden reconstruir a partir del registre, per això la reproducció és un invariant fonamental. Aquesta separació entre la “font de veritat” (registre de confirmació) i la “interfície de consulta” (projeccions) és fonamental per a l’arquitectura d’AssetCore.

  • Construït aplicant esdeveniments del registre de commits (procés de reproducció, vegeu més avall)
  • Optimitzat per al rendiment de consultes (indexat, desnormalitzat per a cerques ràpides)
  • Publicat atòmicament mitjançant intercanvi de snapshots (sense actualitzacions parcials visibles per a les consultes)

Les projeccions són dades derivades. Si es perden, es poden reconstruir a partir del registre de commits. Aquesta propietat és el que fa que AssetCore sigui operativament senzill: sempre es pot reconstruir l’estat de la consulta a partir del registre, i la durabilitat és una elecció de desplegament. Sense això, perdre un daemon de lectura significaria pèrdua de dades o protocols de replicació complexos. Amb això, perdre un daemon de lectura és inconvenient (temps de reconstrucció) però no catastròfic.

El que guanyeu: estat de consulta descartable (reconstrucció a voluntat), llibertat per canviar l’estructura de projecció (repetició amb nova lògica), confiança que les analítiques/notificacions mai es desvien de l’estat operatiu (tots consumeixen el mateix registre). El que renuncieu: el temps de reconstrucció després de fallades escala amb la mida del registre, tot i que els punts de control fan que això sigui manejable.

Punts de control

Els punts de control registren el progrés a través del registre de compromisos. Aceleren la recuperació i permeten raonar exactament quant estat s’ha aplicat. Sense punts de control, cada reinici requeriria reproduir tot el registre des del principi—factible per a sistemes petits, catastròfic per a càrregues de treball de producció amb milions d’esdeveniments.

  • Escriptura daemon: Fa un seguiment de la darrera seqüència compromesa (per saber on reprendre després d’un error)
  • Llegir daemon: Fa seguiment de l’última seqüència aplicada (per poder reprendre la reproducció sense tornar a aplicar esdeveniments)

Els punts de control permeten:

  • Inici ràpid: Reprèn des del punt de control, no des del principi (reproduint 1.000 esdeveniments en comptes de 1.000.000)
  • Recuperació de fallades: Reproduir des de la posició de control (vegeu Model d’execució)
  • Càlcul de frescor: Comparar les marques d’aigua de la seqüència mundial (retard = commit_log_seq - projection_seq)

El que guanyeu: temps d’inici mesurat en segons i no en hores, finestres de recuperació predecibles, monitoratge de frescor en temps real. El que renuncieu: sobrecàrrega de punts de control (escriptures de captures periòdiques), tot i que aquestes són lleugeres i configurables.

Metadades de Frescor

Les respostes de lectura inclouen informació de frescor; els clients poden passar x-assetcore-min-world-seq per bloquejar fins a una seqüència mínima. Així és com s’aplica la lectura dels teus escrits i la consistència estricta a la frontera del client. Sense un seguiment de frescor explícit, no tindries idea si una consulta ha retornat dades obsoletes o dades fresques—la depuració es converteix en un joc d’endevinalles.

{
  "freshness": {
    "namespace": 1,
    "world_seq": 42,
    "commit_log_world_seq": 45,
    "lag": 3,
    "lag_ms": 125
  }
}
  • world_seq: La darrera seqüència aplicada a la projecció de lectura (el que veuen les consultes)
  • commit_log_world_seq: L’última seqüència de registre de commit observada (el que s’ha compromès)
  • lag: La diferència en commits (quants lots estan endarrerits)
  • lag_ms: La diferència de temps en mil·lisegons (quants anys té la dada)

La diferència és el lag: quants commits no s’han aplicat encara (i quant de temps dura aquest buit en mil·lisegons). Aquest lag és normal i esperat en sistemes basats en esdeveniments: és el cost de la separació entre escriptura i lectura. La part crítica és que és mesurat i exposat, no amagat.

El que guanyeu: visibilitat sobre l’antiguitat (saber quan les dades són actuals), capacitat per fer complir la coherència (bloquejar lectures fins que siguin prou actuals), informació per a la depuració (correlacionar problemes de consulta amb pics de retard). El que renuncieu: càrregues de resposta lleugerament més grans (metadades d’actualitat en cada lectura), però el valor operatiu val la pena.

Procés de Repetició

El replay és el mecanisme que manté les projeccions sincronitzades amb el registre de compromisos. No és només una funció de recuperació; és el nucli del bucle operatiu per al daemon de lectura. Entendre el replay és entendre com funciona AssetCore.

Quan el daemon de lectura segueix el registre de compromisos:

  1. Obtenir el següent lot després del punt de control (des de l’emmagatzematge del registre de confirmacions)
  2. Aplica cada esdeveniment mitjançant els setters L1 (vegeu Runtime Model per a detalls de la capa)
  3. Actualitzar el punt de control (registrar el progrés)
  4. Publicar nova instantània (intercanvi atòmic, sense actualitzacions parcials visibles)

Els esdeveniments són idempotents: aplicar el mateix esdeveniment dues vegades produeix el mateix estat. Això fa que la reproducció sigui segura per tornar a intentar i és el que permet la recuperació determinista després de fallades parcials. Més important encara, significa que la reproducció no és fràgil: si no estàs segur si un esdeveniment s’ha aplicat, simplement aplica’l de nou.

Per què el replay és una característica clau: No es tracta només de la recuperació de fallades. És depuració viatjant en el temps (replay a les 15:47 del dimarts i inspeccionar l’estat exacte), simulació (replay d’esdeveniments de producció contra lògica experimental), anàlisis (replay del registre en una estructura de projecció diferent) i proves (verificar el comportament contra fluxos d’esdeveniments reals). Els sistemes sense replay determinista no poden fer cap d’això de manera fiable.

Flux de Recuperació

Després d’un error, AssetCore es recupera automàticament sense intervenció manual. Aquesta és una de les propietats més valuoses operativament de l’arquitectura—sense pàgines a les 3 AM per restaurar l’estat manualment.

Després d’un accident:

  1. Carrega el punt de control des del disc (instantània de l’últim estat conegut correcte)
  2. Recuperar esdeveniments de la posició de control (només esdeveniments que encara no s’han aplicat)
  3. Reproduir esdeveniments per reconstruir l’estat (a través de L1 setters, ràpid i determinista)
  4. Reprendre el bucle de cua normal (tornar a l’operació en estat estable)

Perquè els esdeveniments porten un estat posterior (vegeu Model d’execució), la reproducció no necessita tornar a executar la lògica empresarial. Simplement estableix els valors finals, eliminant la no determinació durant la recuperació. Això és el que fa que la recuperació sigui ràpida (sense sobrecàrrega de validació) i fiable (sense possibilitat de divergència).

El que guanyeu: recuperació automàtica (sense passos manuals), temps de recuperació previsible (es redueix amb esdeveniments des del punt de control), confiança que l’estat recuperat és idèntic en bytes a l’estat anterior al fallament. El que renuncieu: la recuperació no és instantània—requereix un temps proporcional a l’interval del punt de control, però normalment són segons i no minuts.

Com s’integra al sistema

Escriure Ruta

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

El daemon d’escriptura actualitza el seu punt de control després d’una persistència exitosa.

Llegir Ruta

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

El daemon de lectura publica instantànies abans d’actualitzar el seu punt de control. Això assegura:

  • Les consultes sempre veuen un estat coherent
  • Les caigudes no perden treball aplicat però no controlat

Informes de Frescor

El punt final de salut de lectura informa sobre el retard per a un espai de noms:

{
  "status": "ready",
  "freshness": {
    "namespace": 1,
    "world_seq": 98,
    "commit_log_world_seq": 100,
    "lag": 2,
    "lag_ms": 250
  }
}

Monitoritza això per detectar:

  • Funcionament normal (retard proper a 0)
  • Augment temporal (pulsos de retard que després es recuperen)
  • Problemes sistemàtics (el retard creix contínuament)

Invariants i garanties clau

Consistència eventual

Les projeccions reflectiran eventualment tots els esdeveniments compromesos:

  • El daemon de lectura segueix contínuament el registre
  • El retard pot augmentar durant els pics però es recupera
  • Cap esdeveniment compromès és permanentment invisible

Publicar-Abans-Del-Punt-De-Control

Les instantànies es publiquen abans que els punts de control s’actualitzin:

  • Les consultes veuen dades que es garanteix que s’apliquen
  • Els bloquejos no fan que les dades “desapareguin”
  • Reproduccions de recuperació des del darrer punt segur

Reproducció Determinista

La reproducció produeix un estat idèntic:

  • Els esdeveniments porten valors post-estat
  • No hi ha lògica empresarial durant la reproducció
  • Mateixos esdeveniments → mateix estat

Seguretat del Punt de Control

Els punts de control es persisteixen de manera atòmica:

  • No s’escriuen punts de control parcials
  • La recuperació sempre troba un punt de control vàlid
  • El progrés mai es perd en els reinicis

Vegeu també