--- title: "Dashboard in tempo reale con Laravel, Redis e WebSockets" description: "Come creare dashboard e allarmi in tempo reale su flussi ad alto volume con Laravel: ingestione con buffer, code, broadcasting, aggregazione e soglie dinamiche." canonical: https://sdk.enterprises/it/insights/real-time-dashboards-laravel language: it --- # Dashboard in tempo reale con Laravel, Redis e WebSockets Aggiornato il: 2026-09-25 > Laravel può alimentare dashboard in tempo reale su flussi ad alto volume se gli eventi grezzi non arrivano mai al browser: mettete l'ingestione in un buffer su Redis, elaboratela con worker in coda, pre-aggregate i dati in intervalli di tempo e trasmettete via WebSockets solo i riepiloghi. Fate scattare gli allarmi su soglie dinamiche ricavate dallo storico recente invece che su limiti fissi, e aggiungete una piattaforma di streaming dedicata quando le esigenze di replay, di ordinamento o di volume superano le code Redis. ## Tenete gli eventi grezzi lontani dal browser L'errore più comune nelle dashboard in tempo reale è inviare ogni evento in arrivo a ogni schermo collegato. Ad alto volume i browser restano indietro, il server WebSocket si satura e il grafico diventa comunque illeggibile. Dividete il sistema in quattro fasi: ingestione, elaborazione, aggregazione e trasmissione. Ogni fase ha una propria capacità e può rallentare senza trascinare con sé le altre. La dashboard riceve aggiornamenti aggregati a cadenza fissa, per esempio una volta al secondo per pannello, non eventi grezzi. I nostri ingegneri hanno usato questa struttura per Slump, una piattaforma di monitoraggio in tempo reale dell'andamento della rete 5G, degli indicatori di capacità e della previsione di saturazione per operatori di tutta la Spagna meridionale, costruita su un backend Laravel 11 e 12 che ingerisce dati in streaming ad alto volume. ## Mettete l'ingestione in un buffer, così i picchi di traffico non diventano disservizi L'endpoint di ingestione deve fare il meno possibile: validare il payload, aggiungerlo a un buffer e rispondere. Parsing, arricchimento e scritture nel database spettano ai worker. A volumi moderati Redis funziona bene come buffer. Inserite gli eventi in una lista o in uno stream Redis e lasciate che i worker li prelevino a lotti, perché un inserimento a lotti costa al database molto meno di centinaia di inserimenti riga per riga. - Validate lo schema e scartate gli eventi malformati già all'ingresso - Rispondete in fretta e non scrivete mai nel database principale all'interno della richiesta - Leggete dal buffer a lotti invece che un evento per job - Limitate la lunghezza del buffer e fate scattare un allarme quando cresce, così la contropressione è visibile prima di trasformarsi in perdita di dati ## Scalate l'elaborazione con code separate e Horizon Le code di Laravel basate su Redis vi danno worker che potete aggiungere in orizzontale. Laravel Horizon mostra il numero di worker per coda, il throughput e i tempi di attesa: è così che verificate che l'elaborazione tenga il passo con l'ingestione. Separate le code per priorità. La valutazione degli allarmi non deve mai aspettare dietro un arretrato di rielaborazioni storiche: date a elaborazione, aggregazione, allarmi ed esportazioni code e gruppi di worker propri. Rendete ogni job idempotente. Gli stream riconsegnano gli eventi, i worker si bloccano a metà lotto e i nuovi tentativi capitano: elaborare due volte lo stesso evento non deve raddoppiare un contatore. Spesso basta un identificativo dell'evento verificato in un set Redis di breve durata. ## Aggregate in intervalli di tempo prima di trasmettere Le dashboard mostrano tassi, medie, percentili e tendenze, non singoli eventi. Calcolateli nei worker in intervalli di tempo fissi, per esempio al secondo e al minuto, per ogni entità che visualizzate: una cella, una regione, un cliente. Tenete gli aggregati in tempo reale in Redis, con hash o sorted set indicizzati per intervallo, e scrivete nel database ogni intervallo chiuso per lo storico. La progettazione delle query su queste tabelle storiche conta quanto il percorso in tempo reale, perché gli utenti allargheranno la vista a un giorno o a una settimana. Su Slump, la riprogettazione del caching Redis e l'ottimizzazione delle query hanno ridotto la latenza di ingestione, ed è questo che ha mantenuto aggiornata la vista in tempo reale sotto carico. ## Trasmettete riepiloghi via WebSockets con Reverb o un servizio gestito Il broadcasting di Laravel invia eventi su canali a cui il frontend si iscrive tramite Laravel Echo. Laravel Reverb è il server WebSocket ufficiale di Laravel, e servizi gestiti come Pusher o Ably funzionano attraverso la stessa API di broadcasting. - Trasmettete a intervalli regolari partendo dallo stato aggregato, non una volta per ogni evento in arrivo - Usate canali privati e autorizzate ogni iscrizione lato server, così gli utenti vedono solo le entità che sono autorizzati a vedere - Inviate snapshot compatti o differenze, non interi set di dati - Alla riconnessione, fate caricare al client lo stato attuale via HTTP, poi riprendete lo stream - Man mano che le connessioni crescono, fate girare più istanze di Reverb dietro un load balancer, con Redis pub/sub tra di loro ## Fate scattare gli allarmi su soglie dinamiche invece che su limiti fissi Sulle metriche in streaming le soglie fisse sbagliano in entrambe le direzioni. Il traffico delle 3 di notte non ha nulla a che vedere con quello delle 20, quindi un limite unico o scatta tutta la notte o non vede i problemi di giorno. Una soglia dinamica confronta ogni nuovo valore con un riferimento ricavato dallo storico recente per la stessa entità e lo stesso momento della settimana. Una versione semplice e spiegabile tiene una media mobile e una deviazione standard per entità e per ora della settimana, e fa scattare un allarme quando il valore resta fuori da quella banda per diversi intervalli consecutivi. Su Slump, gli allarmi dinamici sulle anomalie hanno ridotto il monitoraggio manuale, perché gli operatori venivano avvisati delle deviazioni reali invece di restare a guardare gli schermi. - Richiedete una persistenza, per esempio tre intervalli consecutivi fuori banda, per ridurre il rumore - Tenete un solo allarme aperto per entità e per condizione, aggiornato invece che ripetuto - Includete in ogni allarme il valore attuale, il riferimento, la banda e un link al pannello - Rivedete regolarmente gli allarmi silenziati o ignorati e regolate la banda ## Sappiate quando aggiungere una tecnologia di streaming dedicata Laravel con Redis copre molto terreno, ma ha dei limiti. Valutate Kafka, Redpanda o un servizio di streaming gestito, spesso con un motore di elaborazione di flussi come Apache Flink, quando vi servono una conservazione lunga e il replay degli eventi grezzi, un ordinamento rigoroso per chiave su molti consumer, oppure un throughput che fa della memoria di Redis il collo di bottiglia. Il passaggio non deve avvenire tutto in una volta. Tenete Laravel per l'API, le dashboard, la gestione degli allarmi e il broadcasting, e mettete lo stream a monte della fase di aggregazione. Costruiamo ed estendiamo sistemi in tempo reale di questo tipo, dall'ingestione fino alle regole di allarme su cui contano gli operatori. ## Punti chiave - Non inviate mai eventi grezzi ai browser; trasmettete riepiloghi aggregati a cadenza fissa. - Mantenete leggero l'endpoint di ingestione e mettete gli eventi in un buffer su Redis per un'elaborazione a lotti da parte dei worker. - Separate le code per priorità e rendete ogni job idempotente, così i nuovi tentativi non possono falsare i contatori. - Le soglie dinamiche basate sullo storico recente producono allarmi meno numerosi e più utili dei limiti fissi. - Aggiungete Kafka o una piattaforma simile quando vi servono replay, ordinamento rigoroso o volumi oltre le possibilità di Redis, e tenete Laravel per il livello applicativo. ## Domande frequenti ### Laravel regge dashboard in tempo reale su dati ad alto volume? Sì, se l'architettura tiene il lavoro pesante fuori dal percorso delle richieste: un endpoint di ingestione leggero, un buffer Redis, worker in coda che aggregano in intervalli di tempo e trasmissioni WebSocket limitate ai riepiloghi. Laravel serve allora l'API, le dashboard e gli allarmi, mentre i worker scalano in modo indipendente. ### Meglio Laravel Reverb o Pusher per i WebSockets? Reverb è il server WebSocket ufficiale di Laravel e gira sulla vostra infrastruttura, cosa adatta ai team che vogliono controllare costi e localizzazione dei dati. Pusher o Ably eliminano il lavoro operativo di gestire server WebSocket. Entrambi usano la stessa API di broadcasting di Laravel, quindi potete cambiare in seguito. ### Che cos'è una soglia dinamica nel monitoraggio? Una soglia dinamica è un limite di allarme calcolato dallo storico recente della stessa metrica, per la stessa entità e lo stesso momento della settimana, invece che un numero fisso. Si adatta ai cicli giornalieri e settimanali, così gli allarmi scattano sulle deviazioni reali e non sui picchi normali. ## Servizi correlati - [Software su misura](https://sdk.enterprises/it/services/product-engineering)