Issue 10036 · Resilienza
· 5 min
Backpressure: rendere visibile la capacità prima che il sistema collassi
Quando la domanda supera la capacità downstream, il limite deve propagarsi verso monte; se non basta, servono policy esplicite di overload protection.
Obiettivo
Progettare meccanismi che adeguino la domanda alla capacità downstream prima che code, memoria e dipendenze collassino.
practice
Cosa devi fare in pratica
In un sistema distribuito, la backpressureGlossarioBackpressureUn meccanismo con cui un consumer più lento limita o segnala il ritmo del lavoro in ingresso.Apri la voce completa non è un dettaglio di implementazione: è una scelta architetturale per rendere esplicita la capacità reale. Il punto è semplice: se un servizio a valle non riesce a sostenere il ritmo, il sistema a monte deve reagire prima di saturare code, thread, memoria o connessioni. In pratica, devi decidere dove nasce il segnale di saturazione e fino a dove si propaga. La backpressure serve soprattutto a far rallentare chi produce lavoro o a limitare la concorrenza in funzione della capacità downstream. Se il producer non può o non deve rallentare abbastanza, entrano in gioco policy diverse ma complementari di overload protection, come rifiuto esplicito, load shedding o prioritizzazione. Chiamarle tutte "backpressure" nasconde una decisione importante: una cosa è propagare un limite di capacità, un'altra è scegliere quale lavoro sacrificare quando quel limite non può essere rispettato. Come architetto, chiediti sempre: qual è la capacità sostenibile del downstream? dove deve propagarsi il segnale? quale comportamento voglio quando rallentare non basta? e quali metriche renderanno visibile la saturazione al team? Senza queste risposte, la protezione dal sovraccarico resta implicita e il sistema continua a fallire in ritardo, in modo più costoso.
trade-offs
I trade-off da esplicitare
La backpressure migliora la stabilità, ma introduce compromessi che vanno dichiarati chiaramente. Il primo è tra throughput e protezione: rallentare il flusso preserva la capacità downstream, ma può aumentare la latenza percepita. Se il rallentamento non è sufficiente, policy di overload protection come rifiuto, shedding o prioritizzazione rendono esplicito quali richieste possono essere sacrificate, con un impatto diretto sul business. Il secondo è tra semplicità e controllo: più livelli di propagazione del segnale e più policy di protezione rendono il comportamento più robusto, ma anche più difficile da progettare e da osservare. C’è poi un trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa spesso sottovalutato: buffer grandi danno l’illusione di assorbire il picco, ma in realtà nascondono il sovraccarico e rimandano il collasso. In molte architetture enterprise, è meglio rendere visibile il limite e applicare una degradazione controllata che vedere crescere code e timeoutGlossarioTimeoutUn limite definito a quanto un’operazione attende prima di considerare il tentativo non riuscito.Apri la voce completa fino a bloccare tutto. La domanda non è se il sistema soffrirà sotto carico; è dove vuoi che si manifesti il limite e con quale impatto sul business.
enterprise-example
Esempio enterprise realistico
Immagina una piattaforma di order management con un servizio di ingestion che riceve eventi da canali diversi e li inoltra a un motore di pricing e a un sistema di frodi. Durante un picco promozionale, il motore di frodi rallenta e il rischio è che l’ingestion continui a produrre eventi finché la coda cresce senza controllo. Con una backpressure progettata bene, il segnale di saturazione del downstream risale verso l’ingestion, che riduce il rate o limita la concorrenza. Se questo non basta perché parte del traffico non può essere rallentata, il sistema può applicare una policy separata di overload protection: differire richieste non urgenti, fare shedding del lavoro sacrificabile o mantenere un percorso preferenziale per gli ordini ad alta priorità. In meeting, la distinzione diventa concreta: quanto possiamo rallentare il flusso e, superato quel limite, quale lavoro siamo disposti a non accettare subito? Il valore non è solo tecnico. Se saturazione, backpressure e shedding sono visibili e misurati separatamente, il team operativo può distinguere tra un picco atteso e un degrado anomalo, e il business può capire perché una protezione intenzionale è migliore di un collasso indistinto.
references
Per approfondire
Fonti esterne autorevoli per approfondire il tema della backpressure e del controllo di flusso nei sistemi distribuiti. • Reactive Streams Specification - Reactive Streams - https://www.reactive-streams.org/ • Java PlatformGlossarioPlatformUn insieme gestito di capability riusabili che permette ai team di consegnare e operare soluzioni tramite interfacce definite.Apri la voce completa, Standard Edition API Specification: Flow - Oracle - https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/Flow.html • Designing Data-Intensive Applications - Martin Kleppmann - https://dataintensive.net/
Da ricordare
La backpressure funziona quando il sistema propaga verso monte il limite di capacità; load shedding, rifiuto e prioritizzazione sono policy complementari da usare quando rallentare non basta.
Per la prossima riunione
Se dovessimo applicare la backpressure a questo flusso, dove dovrebbe nascere e propagarsi il segnale di saturazione, e quale policy useremmo se rallentare non fosse sufficiente?
Una domanda per te