Avete presente quella sensazione di quando cercate di riparare un vecchio Game Boy e vi ritrovate a dover configurare un intero ecosistema di strumenti per smontare la scocca? Ecco, la gestione dei workflow moderni sta prendendo esattamente questa direzione: una complessità inutile che fa venire il mal di testa.
Sempre più spesso, quando si parla di ‘durable execution’ o di sistemi che devono resistere ai crash, la prima risposta che scatta nel cervello è: ‘Serve un cluster Postgres, una partizione dedicata e un team di SRE che dorme poco’. Ma la verità è molto più… minimalista. Recentemente è emersa un’idea che mi ha fatto saltare sulla sedia: per un’enorme classe di sistemi, SQLite è tutto quello che vi serve.
Il concetto è geniale nella sua semplicità. Se il vostro obiettivo è mantenere lo stato di un processo (un workflow, un agente AI, un task di automazione) in modo che possa ripartire se tutto esplode, non vi serve necessariamente un database centralizzato e pesantissimo. Vi serve che lo ‘stato’ sia persistente. E SQLite, essendo essenzialmente un file sul disco, è la definizione stessa di persistenza senza fronzoli. Niente network hop, niente latenza da protocolli complicati, niente ‘oh no, il database remoto non risponde’.
E come gestiamo il problema del backup se il disco muore? Qui entra in gioco Litestream, il vero pezzo forte per chi ama smanettare. Questo strumento sincronizza in modo asincrono i cambiamenti del database verso uno storage compatibile con S3. È come avere un sistema di salvataggio automatico su una vecchia console: se la macchina si spegne, il tuo progresso è al sicuro in cloud. Certo, c’è il rischio di perdere gli ultimissimi millisecondi di scrittura se tutto va in fumo istantaneamente, ma per la maggior parte degli esperimenti, bot o agenti AI, è un compromesso che accetterei volentieri.
Da maker e smanettoni, questo approccio ci parla direttamente. Ci permette di lanciare una flotta di micro-container o micro-VM, ognuno con il proprio piccolo database SQLite, senza dover gestire l’incubo di un’infrastruttura condivusa enorme e costosa. È l’approccio ‘un componente, un compito’, proprio come quando progettiamo una macchina CNC o un sistema di riciclo plastica: vogliamo che ogni modulo sia indipendente e robusto.
Ovviamente, non è la bacchetta magica per tutto. Se state costruendo il prossimo social network globale con milioni di scritture al secondo, continuate pure a venerare Postgres. Ma se il vostro obiettivo è creare agenti intelligenti, prototipi che funzionano, o sistemi di automazione che non richiedano un master in sistemi distribuiti solo per essere accesi, allora smettete di cercare l’iper-complessità. Torniamo alle basi. Torniamo a ciò che è semplice, portabile e, soprattutto, funzionante.