Choose and deploy message broker #12
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Evaluate and deploy NATS JetStream (preferred) vs Redis Streams.
Il broker è ancora necessario?
Quando hai progettato l'architettura, il broker serviva per disaccoppiare gli agenti dall'Arbiter. Ma oggi hai già agent_messages su PostgreSQL che fa
esattamente quella cosa — e l'hai appena costruita.
Quello che hai adesso:
Agente n8n → INSERT agent_messages (arbiter_decision = NULL)
Arbiter → SELECT ... WHERE arbiter_decision IS NULL (cron)
→ UPDATE arbiter_decision = 'notify'/'defer'/'discard'
Questo è un message broker — persistente, queryabile, con audit log. Il 90% del valore di NATS/Redis Streams lo hai già gratis con Postgres.
L'unico caso che Postgres non copre
Il bypass high-priority: quando un agente rileva un alert critico (es. disco pieno, bolletta scaduta), deve svegliare l'Arbiter immediatamente senza aspettare il
cron.
Soluzione banale: n8n webhook diretto. L'agente chiama il webhook dell'Arbiter con priority: high. Zero infrastruttura aggiuntiva.
Se vuoi comunque un broker "vero"
┌─────────────────────────┬─────────────────────────┬────────────────────────────────┐
│ │ Redis Streams │ NATS JetStream │
├─────────────────────────┼─────────────────────────┼────────────────────────────────┤
│ Già in cluster │ ✅ sì (Redis HA attivo) │ ❌ da deployare │
├─────────────────────────┼─────────────────────────┼────────────────────────────────┤
│ n8n supporto nativo │ ✅ nodo Redis nativo │ ⚠️ solo via HTTP/custom │
├─────────────────────────┼─────────────────────────┼────────────────────────────────┤
│ Overhead operativo │ zero (già gestito) │ nuovo componente da monitorare │
├─────────────────────────┼─────────────────────────┼────────────────────────────────┤
│ Replay messaggi │ ✅ sì │ ✅ sì (più potente) │
├─────────────────────────┼─────────────────────────┼────────────────────────────────┤
│ Adatto al volume │ ✅ (pochi msg/ora) │ ✅ ma sovradimensionato │
├─────────────────────────┼─────────────────────────┼────────────────────────────────┤
│ Caso d'uso ALPHA │ sufficiente │ overkill │
└─────────────────────────┴─────────────────────────┴────────────────────────────────┘
La mia raccomandazione
Non deployare né NATS né Redis Streams adesso. Usa:
Se in futuro il volume cresce o ti servono pattern più complessi (fan-out multi-subscriber, replay, retention policy), aggiungi Redis Streams (già lì, zero
setup).
NATS JetStream lo valuterei solo se ALPHA_PROJECT diventasse multi-household o dovesse scalare orizzontalmente — scenari lontani dal tuo homelab.