Cos'è il backpressure?

Il backpressure è il meccanismo con cui un sistema segnala a chi gli invia dati che non riesce a processarli al ritmo con cui arrivano, così che il produttore rallenti oppure l'eccesso venga gestito senza sorprese, invece di lasciare che si accumulino fino a esaurire la memoria o che vadano persi senza avviso. Si presenta ogni volta che un consumatore è strutturalmente più lento del produttore a monte: un picco di traffico, un database rallentato da un lock, un consumer che si riavvia dopo un guasto. Senza un meccanismo esplicito, la differenza di velocità si accumula in un buffer non limitato finché la memoria non si esaurisce o la latenza non rende il sistema inutilizzabile. Un'architettura ben progettata non evita il picco, lo rende visibile e gestibile: propaga il segnale di saturazione a ritroso lungo la catena, usa buffer a capacità finita invece che illimitata, e sceglie esplicitamente cosa fare quando la capacità si esaurisce: bloccare il produttore, scartare i messaggi a bassa priorità oppure campionare.

Le strategie concrete, non solo il principio

Il backpressure non è un'unica tecnica ma una famiglia di strategie, e la scelta tra loro è una decisione di design, non un dettaglio implementativo. La prima è il consumo a ritmo del consumatore, come nel modello pull di Apache Kafka, dove è il consumer a richiedere i batch successivi quando è pronto, cosicché il broker non debba mai spingere dati più velocemente di quanto il lato lento riesca a leggerli. Attenzione a cosa questo protegge: il pull mette al riparo il tratto broker-consumatore, non il produttore, che continua ad accodare mentre il lag del consumer cresce, fino a toccare il limite di retention. La seconda è il blocco a monte vero e proprio, dove il produttore smette di scrivere finché non si libera spazio. La terza è il buffering limitato con politica di scarto esplicita: una coda con capacità massima che, una volta piena, applica una regola dichiarata (drop-oldest, drop-newest, oppure scarto per priorità) invece di crescere senza limite. La quarta è il sampling o il throttling, utile quando la precisione di ogni singolo evento conta meno della salute complessiva del sistema, per esempio nella telemetria ad alta frequenza. La quinta è il backoff, dove il produttore rallenta progressivamente in risposta a segnali di saturazione (errori 429, latenza crescente) invece di continuare a inviare al ritmo originale. Framework di stream processing come Apache Flink implementano il backpressure end-to-end lungo l'intera pipeline: se un operatore a valle rallenta, il segnale risale automaticamente fino alla sorgente, che riduce il ritmo di lettura senza intervento manuale.

Un esempio enterprise

Una piattaforma di e-commerce ingerisce eventi di clickstream in tempo reale per alimentare un motore di raccomandazione: durante un evento promozionale il traffico decuplica in pochi minuti, e il servizio che arricchisce ogni evento con i dati del catalogo, una chiamata a un database esterno, non riesce a tenere il passo. Senza backpressure, la coda intermedia cresce senza limite finché il processo esaurisce la memoria e va in crash, perdendo in un colpo solo tutti gli eventi bufferizzati, compresi quelli già pagati in termini di elaborazione. Con una coda a capacità finita e una politica di backoff sul produttore, il sistema invece rallenta l'ingestione quando la coda si avvicina alla soglia, accetta una latenza più alta per gli eventi durante il picco, e resta in piedi fino a quando il traffico rientra: un degrado misurabile e comunicabile al business, non una chiamata nel cuore della notte con perdita di dati.

Perché conta per chi decide

Un sistema senza backpressure non è più veloce di uno che ce l'ha, sposta soltanto il momento del fallimento da un rallentamento visibile a un crash improvviso, spesso nel momento di traffico più alto, quindi il più costoso da subire. La domanda da fare in fase di design non è "quanto throughput regge il sistema", ma "cosa succede quando il throughput lo supera": se la risposta è "non lo sappiamo" o "il processo va in OOM", il rischio operativo è reale anche se il carico medio è ben sotto la capacità nominale. Progettare il backpressure esplicitamente, invece di scoprirlo durante un incidente, costa meno quando si progetta un'architettura a eventi di quanto costi in produzione, e distingue un'architettura dati enterprise da un prototipo che ha funzionato solo perché non è mai stato messo davvero sotto pressione.