Cosa succede quando il verificatore di Rexfin va giù (e come si riprende)

Il motore di verifica di Rexfin si trova al centro di ogni risposta citata e di ogni decisione di export. Non è una dipendenza incidentale, è tutto il punto. Bloccare un export non verificato significa qualcosa solo se ciò che esegue il blocco è effettivamente attivo, veloce e osservabile quando conta. Quindi la domanda onesta non è “Rexfin ha uptime,” è “cosa succede nel momento in cui non lo ha.”

Un budget, non una speranza

Sia il percorso di verifica sia il percorso di risposta portano un obiettivo interno di livello di servizio, tracciato rispetto al traffico reale anziché scelto per suonare rassicurante in un questionario di sicurezza. La verifica di un modello già inviato ha un budget di pochi secondi; una risposta citata appena generata, che comporta retrieval e generazione prima che la verifica venga eseguita, porta un budget più ampio proprio suo, con un tetto rigido sulla coda lenta. La disponibilità è tracciata rispetto a un obiettivo interno su una finestra mobile di 30 giorni, con un budget di errore associato, la stessa regola dietro il modello di supporto: un numero viene pubblicato solo una volta che è uno che possiamo davvero sostenere.

Il motivo per cui un budget conta più di una singola cifra di uptime: viene accompagnato da un allerta sul tasso di consumo. Un’interruzione totale improvvisa fa scattare una notifica entro l’ora in cui accade, non a fine mese quando il budget è già esaurito. Un degrado lento e progressivo apre un ticket ben prima che il budget si esaurisca. E un rifiuto legittimo, il verificatore che blocca correttamente un set di dichiarazioni che fallisce un controllo di identità, conta come sistema che funziona, non come interruzione. Questa distinzione conta: una metrica di disponibilità che non riesce a distinguere “il gate ha fatto il suo lavoro” da “il gate si è rotto” sta misurando la cosa sbagliata.

Una traccia unica per l’intera risposta

Quando un verdetto è lento o sbagliato, il problema di solito attraversa un confine, retrieval, poi un ciclo di indagine che raccoglie cifre a supporto, poi un writer che produce il testo, poi il verificatore che lo controlla, poi la scrittura nel registro di audit. Rexfin lega tutto questo sotto un’unica traccia, così una risposta lenta è diagnosticabile end to end invece di “è lenta da qualche parte,” che è la frase meno utile in una revisione di incidente. Qualsiasi traccia che termina in un fallimento o in un rifiuto legittimo viene sempre conservata per intero, a prescindere dal campionamento normale, così i casi interessanti non sono mai quelli scartati.

I provider falliscono. La risposta non dovrebbe semplicemente fermarsi.

I fornitori di modelli applicano rate limit e vanno giù, è normale, non eccezionale. Rexfin avvolge ogni chiamata in uscita con un timeout, retry limitati con backoff e un circuit breaker per provider. Una volta che un breaker scatta, la richiesta passa a un percorso in cache o offline invece di restare in sospeso, e la risposta viene onestamente segnalata come degradata, mai restituita silenziosamente come se nulla fosse successo. Questo è ciò che rende operativamente sicuro l’instradamento di compiti diversi verso provider di modelli diversi: un singolo intoppo di un fornitore degrada le risposte di un solo ruolo, non l’intero sistema.

I retry portano una seconda garanzia facile da trascurare: sono idempotenti. Se un client ritenta la stessa richiesta di verifica due volte, Rexfin restituisce lo stesso verdetto memorizzato e lo stesso record di audit invece di aggiungere una seconda voce al registro di audit. Un registro append-only, a prova di manomissione, che potesse accumulare voci duplicate da normali retry di rete non sarebbe affidabile a lungo.

Sotto tutto questo c’è una regola che non si piega mai: una dipendenza che è giù degrada a un avviso, a un errore tipizzato o a un rifiuto, non produce mai un verdetto positivo per un controllo che in realtà non è riuscita a eseguire. Perdere il database significa che il gate dice “non disponibile,” non “pulito.”

Il backup che conta davvero

La garanzia più importante in tutta quest’area non riguarda l’uptime, riguarda cosa sopravvive a un ripristino. Ogni presentazione al board verificata che Rexfin abbia mai emesso vale solo quanto il registro a prova di manomissione che ne sta dietro. Se un guasto al disco o un deploy sbagliato facesse sì che quel registro non potesse essere ripristinato in uno stato in cui la sua prova continua a verificarsi, ogni verdetto precedentemente emesso smetterebbe silenziosamente di essere verificabile, retroattivamente.

Quindi la procedura di ripristino non è considerata completa quando il database torna online. È completa quando la prova di un verdetto precedentemente emesso viene riverificata rispetto ai dati ripristinati e si risolve ancora, la stessa prova che l’auditor di un cliente potrebbe eseguire in modo indipendente. Oggi questo significa backup notturni invece di replica continua, un divario che nominiamo apertamente invece di arrotondare per eccesso, quindi l’attuale punto di ripristino è misurato in ore, non secondi; ciò che è già vero è che i ripristini sono stati testati e sono effettivamente riusciti, quindi il recupero è una capacità testata, non un documento che nessuno ha mai eseguito. È anche qui che conservazione ed eliminazione dei dati si intersecano con l’affidabilità: i dati di un deal eliminato devono essere davvero spariti anche dai backup, non resuscitati silenziosamente alla successiva volta che uno di essi viene ripristinato.

Niente di tutto questo rende Rexfin immune alle interruzioni, i provider vanno comunque giù, i dischi si guastano comunque. Ciò che cambia è cosa succede dopo: un recupero misurato, allertato e in definitiva dimostrabile, invece di una silenziosa speranza che nulla di importante sia andato perso. Per il resto di come la piattaforma è costruita per essere difendibile, vedi l’hub Dentro la piattaforma Rexfin.