Costruzione di un’infrastruttura di bot che non prenda fuoco

Quella volta in cui un bot “semplice” ha distrutto un database

Alcuni anni fa ho implementato quella che pensavo fosse una piccola funzionalità su un bot di produzione. Doveva solo riempire alcuni metadati utente mancanti. Niente di che. Dieci minuti dopo, il database principale si lamentava, gli avvisi riempivano il mio telefono e il bot era bloccato in un ciclo di riavvii.

Il bug non era nella logica di business. Il bug era nell’infrastruttura che non mi ero preso la briga di progettare.

Avevo distribuito un bot che comunicava direttamente con il database, inline, per ogni messaggio. Niente coda. Nessun limite di richieste. Nessuna pressione di ritorno. Quando un’API esterna rallentava, i lavoratori si accumulavano, i conteggi delle connessioni impennavano e il DB riceveva un colpo in faccia.

Quella è stata la giornata in cui ho smesso di pensare “eh, è solo un bot” e ho iniziato a trattare i bot come qualsiasi altro sistema di produzione che può letteralmente rovinare la tua infrastruttura se non sei attento.

Se stai costruendo bot su cui dipendono utenti reali, hai bisogno di infrastruttura. Non di un’infrastruttura gigantesca da tipo-kubernetes-cathedral. Solo i pezzi giusti, collegati correttamente, affinché il bot non cada al secondo in cui diventa popolare o un endpoint API si comporta male.

L’architettura minima viabile del bot che funziona davvero

Parliamo dei pezzi fondamentali. Quando dico “infrastruttura del bot”, intendo le cose che permettono al tuo bot di:

• Resistere a picchi di traffico
• Gestire API esterne lente o inaffidabili
• Recuperare da bug senza necessità di intervento manuale
• Dirti cosa è rotto prima che lo facciano gli utenti

Non hai bisogno di venti servizi per fare questo. Ti servono solo un paio di servizi noiosi, usati in modo coerente.

1. Punto di ingresso senza stato

Il punto di ingresso del tuo bot (webhook/endpoint HTTP/poller) dovrebbe essere il più senza stato e veloce possibile.

• Ricevi l’evento (Slack, Discord, WhatsApp, quello che è).
• Validalo (firma, timestamp).
• Mettilo in una coda.
• Invia rapidamente l’ACK alla piattaforma.

Su un bot di Slack, abbiamo mantenuto il tempo di risposta HTTP sotto i 150 ms in modo costante facendo quasi nulla nel gestore delle richieste. Tutto il lavoro costoso andava ai lavoratori. Questo da solo ha eliminato il 90% dei problemi di timeout casuali di cui la gente incolpava “Slack che è strano”.

2. Una vera coda, non “solo una goroutine”

Mi piacciono RabbitMQ e Redis (tramite qualcosa come bullmq o rq) per la maggior parte dei bot. AWS SQS va bene anche. Scegline uno e impegnati.

La tua coda è dove:

• Dissoci l’ingestione dal processamento
• Controlli la concorrenza (max lavori in corso)
• Gestisci i tentativi e le lettere morte

Per un bot che ho pubblicato nel 2023 che gestiva i webhook di GitHub, siamo partiti senza coda “per mantenere le cose semplici”. A 3000 eventi/minuto durante un grande guasto CI, i server dell’app sono crollati perché ogni richiesta cercava di fare tutto. Siamo passati a SQS + pool di lavoratori, limitati a 50 lavori contemporanei, e lo stesso carico toccava appena la CPU.

3. Processi lavoratori che puoi scalare e terminare

Un lavoratore dovrebbe fare una cosa: prelevare messaggi dalla coda e elaborarli. Questo è tutto. Niente servizio HTTP. Niente ruoli misti.

Un lavoratore sano:

• Ha un chiaro limite di concorrenza (ad esempio, 20 lavori per pod)
• Implementa timeout per le chiamate esterne (ad esempio, 3–5 secondi)
• Utilizza la logica del circuit breaker per allontanarsi da guasti persistenti
• Emette metriche per tipo di lavoro

Quando la CPU aumenta di carico, aggiungi più lavoratori. Quando qualcosa si rompe, puoi ridurre i lavoratori a zero senza toccare il punto di ingresso dell’ingestione.

4. Archiviazione che corrisponde all’uso reale del bot

I bot di solito hanno bisogno di tre tipi di archiviazione:

• Config/stato (preferenze utente, token) → Postgres, DynamoDB, qualsiasi cosa tu sappia realmente gestire.
• Sessioni (contesto della conversazione) → Redis con TTL o il tuo vector store se sono pesanti in LLM.
• Log/eventi (per analisi e debug) → ClickHouse, BigQuery, o anche S3 + parquet.

L’errore è gettare tutto in un unico database. Questo è il modo in cui finisci per avere una scatola misteriosa, lenta e costosa che nessuno vuole toccare.

Fallimenti che affronterai (e come non andare nel panico)

Ogni bot che sopravvive più di un mese in produzione incontra le stesse 5–6 classi di fallimento. Puoi sia prepararti ora, sia fare debug a mezzanotte mentre osservi un dashboard Grafana con le mani tremanti.

1. API esterne che vanno lente o si bloccano

Se il tuo bot chiama Slack, Discord, OpenAI, o qualche CRM di terze parti: assumilo che assolutamente si comporteranno male.

• Usa timeout per ogni richiesta.
• Implementa tentativi con jitter e backoff esponenziale.
• Usa un circuito interruttore in modo da smettere di colpire un servizio rotto.

Su un bot di Telegram che chiama l’API di OpenAI, limitiamo le chiamate simultanee a OpenAI a 40 per regione, e facciamo 3 tentativi con backoff (250ms, 1s, 4s). Durante un guasto regionale nel 2024, le richieste sono rallentate a oltre 20 secondi, ma il resto del sistema è rimasto attivo perché non stavamo accumulando migliaia di lavoratori bloccati.

2. Tempeste di messaggi e tentativi da parte della piattaforma

Slack, WhatsApp e altri ripeteranno i webhook se il tuo endpoint è lento o restituisce 5xx. Se il tuo bot è lento e il tuo gestore non è idempotente, otterrai elaborazioni doppie. O triple.

Risolvilo:

• Rende i gestori idempotenti utilizzando una chiave di deduplica (ID richiesta, ID messaggio).
• Memorizza i marcatori di “elaborato” in uno store veloce (un set Redis con TTL va bene).
• Registra i duplicati in modo da poterli davvero vedere avvenire.

3. Lavori che scappano di mano

Un lavoro che non finisce mai è peggio di un lavoro che fallisce rapidamente. Consuma concorrenza e silenziosamente affama la coda.

Utilizza:

• Timeout rigidi per lavoro (ad esempio, 30 secondi per lavori normali, 5 minuti per quelli pesanti).
• Hook di cancellazione dove il tuo client HTTP o client LLM rispetta la cancellazione del contesto.
• Max tentativi (ad esempio, 5) prima di inviare alla coda delle lettere morte.

Osservabilità: come sapere che il bot sta morendo prima degli utenti

Se non hai visibilità, non hai infrastruttura. Hai vibrazioni.

Al minimo, hai bisogno di tre cose:

1. Metriche

Prometheus + Grafana è ancora la mia scelta predefinita. Traccia:

• Profondità della coda per tipo di lavoro
• Latente di processamento dei lavori (p50/p95)
• Percentuale di errori per integrazione (Slack, OpenAI, CRM, ecc.)
• Percentuale di lavori andati a lettere morte

Un allerta semplice come “profondità della coda > 10.000 per 5 minuti” mi ha salvato più volte di qualsiasi complicata rilevazione di anomalie.

2. Log

Utilizza log strutturati. Non mi interessa se è Loki, ELK o Datadog. Solo:

• Includi ID di correlazione (per utente, per conversazione, per lavoro).
• Registra le risposte delle API esterne quando falliscono (almeno stato + errore).
• Registra i tentativi e le decisioni di backoff.

3. Tracce (opzionale ma molto utile)

OpenTelemetry è realmente utile per i bot che toccano più servizi. Tracciare un singolo messaggio utente dal webhook → coda → lavoratore → API esterna → risposta rende il debug 10 volte più veloce.

Cosa costruirei se iniziassi un bot oggi

Se mi dicessi “Sto iniziando un progetto di bot questo fine settimana, aiutami a non pentirmi della mia vita tra tre mesi”, ecco cosa suggerirei:

• Punto di ingresso HTTP: FastAPI / Express / Go net/http dietro a un semplice bilanciatore di carico.
• Fila: Redis + bullmq (Node) o rq/dramatiq (Python). O SQS se lavori su AWS.
• Lavoratori: distribuzione/processo separato, autoscaling orizzontale basato sulla profondità della coda.
• Archiviazione: Postgres per la configurazione, Redis per le sessioni, S3 per log o trascrizioni a lungo termine.
• Metriche: Prometheus + Grafana, avvisi impostati sulla profondità della coda e sulla percentuale di errori.
• Segreti: Vault o il gestore di segreti del tuo cloud. Non hardcodare mai token. Mai.

Niente di tutto questo è elegante. Questo è il punto. I bot non falliscono perché mancano di una tecnologia nuova e brillante. Falliscono perché le basi vengono ignorate.

Se tratti il tuo bot come un giocattolo, i tuoi utenti lo percepiranno. Se lo tratti come qualsiasi altro servizio di produzione, puoi dormire sonni tranquilli invece di fare debug ai tentativi di Slack a letto.

FAQ

Quanti lavoratori ho realmente bisogno per il mio bot?

Inizia in piccolo. Prendi il tuo tempo medio di lavoro e il tuo picco di messaggi al secondo previsto. Se i lavori richiedono 200 ms e ti aspetti 20 messaggi/sec, sono 4 lavori contemporanei. Moltiplica per 2–3 volte per sicurezza, quindi potrebbero essere 10 lavoratori. Poi osserva CPU, latenza e profondità della coda, e regola in base ai dati reali.

Ho davvero bisogno di una coda per un bot a bassa attività?

Meno di 5 messaggi al minuto e nessuna chiamata esterna pesante? Puoi farne a meno. Non appena aggiungi operazioni costose (chiamate LLM, scritture su DB, API di terze parti), aggiungi una coda. È più economico che fare debug su timeout strani e processamenti duplicati in seguito.

Kubernetes è eccessivo per l’infrastruttura dei bot?

Per la maggior parte dei bot, sì, almeno all’inizio. Alcuni contenitori Docker su ECS, Fly.io, o semplici VM con systemd vanno bene. Kubernetes inizia a dare senso quando hai più bot, servizi condivisi o un’isolamento multi-tenant rigoroso. Fino ad allora, mantienilo noioso e semplice.

🕒 Published: April 4, 2026