Il bus di segnali: 35 automazioni senza orchestratori

Il bus di segnali: come coordino 35 automazioni senza orchestratori

35 processi su 5 piattaforme. Un file markdown che le tiene insieme.

Non ho n8n. Non ho Zapier. Non ho Make. Ho un file di testo che si chiama system-signals.md, diviso in sezioni. Ogni sezione appartiene a un processo. Ogni sezione ha un last_updated in UTC.

Quando una sezione tace, qualcosa non ha girato.

Cos'è il bus di segnali

Il bus di segnali è un pattern di coordinamento basato su un principio semplice: ogni processo autonomo scrive su un canale condiviso quando ha fatto il suo lavoro.

Nel mio sistema il canale è un file markdown con questa struttura:

## nome-processo
last_updated: 2026-09-05T09:01:05Z
owner: nome-routine

<!-- corpo della sezione: cosa ha trovato, cosa ha fatto -->
2026-09-05 | slug | triggered · PUBLISHED

Il processo che legge non sa come gira quello che scrive. Sa solo se la sezione è aggiornata o no.

Perché funziona

Un orchestratore terzo (n8n, Zapier, Make) è un punto di guasto in più:

1. Ha un suo runtime da mantenere
2. Ha una sua API da autenticare
3. Ha una sua interfaccia da aggiornare quando qualcosa cambia
4. Se cade, cadono tutti i processi che coordina

Il bus non cade. È un file. Se il processo che scrive cade, il file rimane dove era. Il silenzio è il segnale: la sezione è ferma, l'allarme è implicito.

Come funziona in pratica

Il mio sistema ha 14 sezioni. Ogni sezione ha:

1. Un owner: il processo responsabile
2. Un last_updated in UTC ISO: non il timestamp del sistema, quello che il processo scrive esplicitamente
3. Una riga di payload per ogni run: data, slug, esito

Al mattino apro il file. Leggo i last_updated. Se una sezione è ferma da più di quanto dovrebbe, la controllo.

Non ho un cruscotto. Non ho notifiche. Ho un file.

Il vantaggio operativo

Il file si legge, si scrive e si verifica con qualunque strumento: un terminale, un editor, uno script Python, un agente Claude.

Ogni processo che scrive sul bus fa un commit su git. Il commit è la prova che il processo ha girato: non l'exit 0, non il log, il commit. Se non c'è commit, non è successo.

35 processi su 5 piattaforme (launchd macOS, Cloud Run, Cloud Scheduler, Nightbox cron, Vercel cron). Tutti scrivono sullo stesso file. Nessuno sa degli altri.

Quando non funziona

Il bus non funziona se:

1. Il processo scrive l'esito prima di eseguire (ho risolto questo con una verifica esplicita prima della scrittura)
2. Due processi scrivono sulla stessa sezione (ogni sezione ha un solo owner)
3. Il file cresce senza potatura (implemento una retention di 30 giorni: le righe oltre il cutoff vanno in archivio)

Se il tuo sistema ha più di 5-6 processi che si parlano in modo stretto (output dell'uno è input dell'altro), il bus diventa bottleneck. Lì vale la pena valutare un orchestratore dedicato.

Lo schema minimo

Se vuoi replicarlo, questo è il formato minimo:

## nome-processo
last_updated: <ISO datetime>Z
owner: <nome del processo>

<data> | <slug o identificatore> | <esito>

1. Una sezione per processo
2. Un commit a ogni run
3. Un last_updated aggiornato esplicitamente dal processo, mai dal sistema

Il bus scala bene fino a 15-20 processi coordinati. Oltre, la sezione diventa rumore.

Salva questo schema se stai costruendo un sistema di agenti AI per la tua azienda.