Model d’execució

El model d’execució defineix com Asset Core processa els canvis d’estat i atén les consultes amb garanties deterministes i auditable. És l’estructura conceptual per a cada API, SDK i flux de treball operatiu que trobareu en altres llocs de la documentació.

Problema que resol aquest concepte

Els sistemes distribuïts s’enfronten a una tensió fonamental entre consistència, disponibilitat i tolerància a particions. Els enfocaments tradicionals sovint sacrifiquen un d’aquests aspectes per aconseguir els altres, cosa que condueix a problemes que són difícils de depurar i encara més difícils de reproduir. En sistemes espacials, aquestes fallades es manifesten com a posicions incorrectes, actualitzacions en conflicte i deriva d’estat irrecuperable.

• Condicions de competència quan múltiples escriptors actualitzen el mateix estat
• Actualitzacions perdudes quan els canvis concurrents s’esborren mútuament
• Comportament no determinista que dificulta la depuració i l’auditoria
• Protocols de consens costosos que afegeixen latència i complexitat

Asset Core resol aquests problemes adoptant una arquitectura de només escriptor amb esdeveniments, intercanviant l’escalabilitat horitzontal d’escriptura per un determinisme absolut i simplicitat. A través d’espais de noms, aquest intercanvi encara escala horitzontalment sense comprometre el contracte.

Idees principals

Món de Sol·licitant Únic

Cada món té exactament un escriptor. Aquesta és l’elecció arquitectònica que fa possible tot el que ve després.

En sistemes distribuïts, múltiples escriptors requereixen coordinació: bloquejos distribuïts, protocols de consens (Raft, Paxos) o consistència eventual amb resolució de conflictes. Cada enfocament intercanvia alguna cosa preciosa, ja sigui latència (bloqueig/consens) o determinisme (consistència eventual). Quan es depura un incident en producció, “consistent eventualment” significa “pot ser inconsistent ara mateix, bona sort.”

Un sol escriptor elimina tota aquesta classe de problemes:

• Sense sobrecàrrega de coordinació: Un escriptor significa que no hi ha bloquejos distribuïts, no hi ha compromís en dues fases, ni sobrecàrrega de protocols de consens. Les transicions d’estat són instantànies i locals.

• Sense condicions de competència: Quan només un procés muta l’estat, les operacions s’executen en un ordre total. Es pot raonar sobre causa i efecte de manera lineal. La depuració es converteix en una anàlisi forense, no en una conjectura probabilística.

• Sense impost de protocol de consens: Raft i Paxos afegeixen 2-3 vegades de latència i una complexitat substancial. Un sol escriptor intercanvia l’escalabilitat horitzontal d’escriptura per simplicitat i velocitat.

El compromís és real: no es pot escalar el rendiment d’escriptura horitzontalment dins d’un sol món. El daemon d’escriptura serialitza tots els compromisos a través d’un únic canal, la qual cosa limita el rendiment d’escriptura a allò que un node pot gestionar. Però AssetCore fa aquest compromís explícit i recupera l’escalabilitat mitjançant el particionament de noms d’espai—cada nom d’espai és un món aïllat d’un sol escriptor. En la pràctica, el rendiment s’escalfa horitzontalment mitjançant el particionament entre noms d’espai. Això fa que el determinisme sigui una elecció de disseny en comptes d’una propietat accidental.

Registre de Compromisos com a Font de Veritat

Tots els canvis d’estat es registren com a esdeveniments en un registre de compromisos d’append-only:

• Els esdeveniments són segellats en lots abans de l’acusament
• Els lots són afegits abans que els clients rebin respostes d’èxit (la durabilitat depèn del backend)
• El registre és el document autoritzat de tot el que ha passat

Aquesta elecció de disseny—tractar el registre com la font autoritzada—té implicacions profundes. Significa que les projeccions són descartables: si perds l’estat de lectura, reprodueix des del registre. Significa que l’analítica i les notificacions mai poden desviar-se de la font de veritat perquè consumeixen el mateix registre. Significa que la depuració forense es converteix en viatge en el temps: reprodueix el registre fins a qualsevol punt i inspecciona l’estat exacte. El backend és connectable, així que pots executar en memòria per a simulacions/proves (ràpid, no durable) o utilitzar backends de fitxer/segmentats per a la persistència en cas de fallada; la interfície està dissenyada per acomodar backends addicionals segons sigui necessari.

Sense això, mantindríeu emmagatzematges operatius i analítics separats, lluitant contra la deriva de sincronització, i perdreu la capacitat de respondre definitivament a la pregunta “quin era l’estat a les 3:47 PM del dimarts quan va ocórrer l’error?” El registre de confirmacions fa que aquesta pregunta sigui trivial. Aquest disseny permet la reproducció determinista: donada la mateixa seqüència d’esdeveniments, qualsevol lector reconstruirà el mateix estat. També garanteix que les analítiques, notificacions i projeccions es derivin sempre de la mateixa font de veritat.

Projeccions

Les projeccions són vistes optimitzades per a la lectura de l’estat derivades del registre de confirmacions:

• El daemon segueix el registre de compromisos per a nous lots
• Els esdeveniments són aplicats mitjançant la reproducció per actualitzar l’estat en memòria
• Les instantànies són publicades atòmicament per al servei de consultes

Les projeccions són eventualment consistents amb el registre de compromisos. La diferència entre els esdeveniments compromesos i les projeccions publicades és el retard de frescor, que es mesura i es fa visible a través de punts d’accés de lectura.

Arquitectura de Tres Capes

El temps d’execució separa les preocupacions en tres capes. Aquesta no és una abstracció arbitrària: és com AssetCore aconsegueix tant el rendiment com la correcció.

Sense separació, cada operació barrejava l’accés a l’emmagatzematge, la validació de la lògica empresarial i la coordinació de transaccions en una única funció monolítica. Això fa que les proves siguin difícils (no es pot provar la validació sense emmagatzematge), la reproducció fràgil (la lògica empresarial durant la reproducció corre el risc de no ser determinista) i el rendiment imprevisible (no es pot optimitzar el camí calent per separat del camí de validació).

Les tres capes d’AssetCore et donen:

Capes	Responsabilitat	Comportament
L1 (Emmagatzematge)	Mutacions de dades en brut	Sense validació, sense esdeveniments
L2 (Operacions)	Lògica empresarial	Valida les precondicions, emet esdeveniments
L3 (Transaccions)	Coordinació	Registra desfer, gestiona la reproducció

L1 (Storage) és la capa de rendiment. Exposa setters simples: “establir aquest saldo a N,” “col·locar aquesta instància a les coordenades (x,y).” Sense validació, sense esdeveniments, només mutació d’estat. Això és el que utilitza la reproducció: aplicació d’estat pura, ràpida i determinista.

L2 (Operations) és la capa de correcció. Valida les precondicions (“existeix aquest contenidor?”, “hi ha espai en aquesta posició?”), executa la lògica empresarial i emet esdeveniments que descriuen què ha canviat. Aquí és on viuen les teves regles de domini.

L3 (Transaccions) és la capa de coordinació. Registra els passos d’anul·lació per a cada operació perquè les fallades puguin activar la reversió. Gestiona el cicle de vida del compromís: executa operacions en seqüència, segella esdeveniments en un lot, afegeix al registre de compromisos, retorna l’èxit.

Aquesta separació assegura que:

• Reproducció ràpida: Els setters de L1 estan optimitzats per a camins ràpids, sense sobrecàrrega de validació
• Lògica empresarial provable: L2 es pot provar sense infraestructura d’emmagatzematge
• Rollback atòmic: El registre d’undo L3 pot revertir qualsevol seqüència d’operacions

El cost: més capes d’abstracció. El guany: pots reproduir milers d’esdeveniments per segon perquè L1 està desacoblat de la lògica de validació de L2.

Com s’integra al sistema

El model d’execució modela cada aspecte d’Asset Core:

Escriure Ruta:

1. El client envia la sol·licitud de compromís
2. Escriure el daemon valida i executa operacions (L2/L3)
3. Els esdeveniments es segellen i s’afegeixen al registre de commits del backend
4. El client rep èxit amb el número de seqüència

Llegir Ruta:

1. Llegir el registre de commits dels daemons
2. Els esdeveniments es reprodueixen mitjançant els setters L1 (idempotents)
3. Les projeccions es publiquen mitjançant intercanvi atòmic
4. Consultes llegides de la projecció actual

Recuperació:

1. Carregar punt de control (últim estat conegut bo)
2. Reproduir esdeveniments des de la posició de punt de control
3. Reprendre l’operació normal

Invariants i garanties clau

Determinisme

Donada la mateixa seqüència d’esdeveniments, la reproducció produeix un estat idèntic en bytes. Això és el que fa possible la depuració de viatge en el temps, la recuperació davant desastres i l’auditoria forense.

El determinisme és més difícil del que sembla. La majoria dels sistemes tenen fonts ocultes de no-determinisme: rellotges del sistema (cada reproducció veu un segell de temps diferent), aritmètica de punt flotant (l’arrodoniment varia segons la CPU), generació de nombres aleatoris (no reproductible) i crides a API externes (resultats diferents cada vegada). Quan la reconstrucció de l’estat depèn de qualsevol d’aquests, la reproducció esdevé probabilística: podries obtenir el mateix estat, o podries no.

AssetCore elimina el no determinisme mitjançant restriccions arquitectòniques:

• Els esdeveniments porten càrregues híbrides (delta + estat posterior), i la reproducció utilitza els camps d’estat posterior (els valors exactes a establir, no les operacions per calcular-los)
• El replay utilitza L1 setters (sense aritmètica, sense validació, només aplicació d’estat)
• No hi ha dependències externes durant la reproducció (sense crides a API, sense lectures del rellotge, sense aleatorietat)

El que això permet: reproduir qualsevol punt del registre i inspeccionar l’estat exacte, reconstruir projeccions des de zero amb confiança, demostrar què va passar quan per a l’auditoria. El que renuncies: no pots cridar APIs externes des de les operacions ni confiar en el temps de rellotge—tot ha de fluir a través del registre de confirmació.

Idempotència

Aplicar el mateix esdeveniment dues vegades no té efecte addicional. Aquesta és la propietat que fa que la reproducció sigui segura després de fallades i errors de xarxa.

Sense idempotència, reproduir esdeveniments és perillós. Si un esdeveniment diu “afegeix 10 a aquest saldo”, reproduir-lo dues vegades afegeix 20—has corromput l’estat. Si un esdeveniment diu “mou la instància a la posició (3,5)”, reproduir-lo pot tenir èxit la primera vegada i fallar la segona (ja hi és), causant un comportament divergent. Els sistemes que no són idempotents han de fer un seguiment exacte dels esdeveniments que s’han aplicat, la qual cosa introdueix una comptabilitat complexa i modes de fallada.

AssetCore fa que la repetició sigui idempotent per disseny:

• Els esdeveniments porten l’estat final a establir (no deltes a aplicar)
• La reproducció simplement sobreescriu amb aquell estat (aplicar “set balance to 50” dues vegades resulta en 50, no en 100)
• Segur de tornar a provar després de fallades (si no estàs segur que un esdeveniment s’ha aplicat, simplement aplica’l de nou)

El que això permet: recuperació de fallades sense lògica de reanudació complexa, reintents sense corrupció d’estat, confiança que “reproduir el registre” sempre produeix el mateix resultat. El que renuncies: els esdeveniments són lleugerament més grans (porten l’estat posterior, no només deltes), però la simplicitat operativa val la pena.

Atomicitat

Totes les operacions d’una transacció tenen èxit o fracassen juntes. Aquesta és la garantia que impedeix la corrupció parcial de l’estat.

Sense atomicitat, una fallada en l’operació 5 de 10 deixa les operacions 1-4 compromeses i 6-10 no executades. El teu estat és ara internament inconsistent: un contenidor creat però mai omplert, una transferència mig executada, una instància moguda però la seva referència pare obsoleta. La depuració requereix reconstruir “el que hauria d’haver passat”, cosa que sovint és impossible. Els usuaris veuen un estat corrupte, les operacions fallen inesperadament i la confiança s’erosiona.

AssetCore aplica l’atomicitat a través d’un registre d’anul·lació:

• Els registres L3 desfan passos durant l’execució (operacions inverses per a cada canvi d’estat)
• Les fallades desencadenen el rollback de tots els canvis (reproduir el registre d’anul·lació a l’inrevés, restaurant l’estat anterior exacte)
• No es veuen compromisos parcials (les consultes mai veuen estats intermedis)

La resposta d’error t’informa QUINA operació ha fallat i per què, però l’estat es manté net. El que guanyes: confiança que les transaccions fallides no deixen rastre, no cal netejar manualment després de fallades, la consistència interna és una garantia i no un esforç. El que renuncies: no pots “confirmar el que ha tingut èxit i saltar el que ha fallat”; si qualsevol operació falla, tota la transacció es desfa. Això no és un error, és el disseny. Si necessites un progrés parcial, divideix la transacció en confirmacions més petites amb punts de control explícits.

Seguretat en cas d’accident

Amb un backend de registre de compromisos durable, el sistema es recupera correctament de les caigudes, sense pèrdua de dades i sense intervenció manual. Això és el que fa que AssetCore sigui segur per executar en producció.

La majoria dels sistemes requereixen procediments operatius curosos després d’un fall: comprovar si hi ha un estat corrupte, reconciliar transaccions en curs, verificar la consistència entre rèpliques, i possiblement restaurar des de còpia de seguretat. Aquests procediments són propensos a errors (els humans poden oblidar passos) i consumeixen temps (la recuperació pot trigar minuts o hores). Pitjor encara, algunes fallades no es poden recuperar automàticament: requereixen correccions manuals de dades o acceptar pèrdues de dades.

L’arquitectura d’AssetCore fa que la recuperació de fallades sigui automàtica i sense pèrdues quan el registre de confirmacions és durable:

• El registre de compromisos sobreviu als reinicis quan està recolzat per emmagatzematge durable
• Els punts de control registren el progrés (instantànies de l’estat de projecció en posicions de registre conegudes)
• La reproducció reconstrueix qualsevol estat que falti (carregar el punt de control, reproduir des d’aquella posició fins al cap del registre)

Després d’un error, el daemon d’escriptura es reprèn a la darrera posició de control i continua processant el registre. Els daemons de lectura recarreguen els seus punts de control i reprodueixen cap endavant. Amb un backend durable, no es perd cap estat (el registre ho té tot), no es requereix intervenció manual (la recuperació és automàtica) i no és possible la corrupció (la reproducció és determinista i idempotent). En modes en memòria, la història és intencionadament efímera i la recuperació és un reinici net. El que guanyeu: simplicitat operativa, confiança en la recuperació davant desastres, sense pàgines a les 3 AM per arreglar estats corruptes. El que renuncieu: el temps de recuperació escala amb el nombre d’esdeveniments des del darrer punt de control, però els punts de control es prenen amb freqüència (configurable, normalment cada pocs segons).

Vegeu també

• Frescura i Repetició - Com de “fresca” és la dada llegida
• Transaccions i Operacions - La unitat atòmica de canvi