--- title: "Realtime dashboards met Laravel, Redis en WebSockets" description: "Zo bouw je met Laravel realtime dashboards en alerts op streams met veel volume: gebufferde ingestie, queues, broadcasting, aggregatie en dynamische drempels." canonical: https://sdk.enterprises/nl/insights/real-time-dashboards-laravel language: nl --- # Realtime dashboards met Laravel, Redis en WebSockets Bijgewerkt: 2026-09-25 > Laravel kan realtime dashboards op streams met veel volume aansturen, zolang ruwe events nooit de browser bereiken: buffer de ingestie in Redis, verwerk die in workers via queues, aggregeer vooraf in tijdvakken en broadcast alleen samenvattingen via WebSockets. Geef alerts op dynamische drempels die zijn afgeleid van de recente geschiedenis in plaats van vaste grenzen, en voeg een apart streamingplatform toe als je behoeften aan replay, volgorde of volume Redis-queues ontgroeien. ## Houd ruwe events weg van de browser De meest gemaakte fout bij realtime dashboards is elk binnenkomend event naar elk verbonden scherm sturen. Bij veel volume raken browsers achter, raakt de WebSocket-server verzadigd en wordt de grafiek toch al onleesbaar. Verdeel het systeem in vier fasen: ingestie, verwerking, aggregatie en broadcast. Elke fase heeft haar eigen capaciteit en kan vertragen zonder de andere mee te sleuren. Het dashboard krijgt geaggregeerde updates in een vast ritme, zoals één keer per seconde per paneel, en geen ruwe events. Onze engineers gebruikten deze opzet bij Slump, een platform voor realtime monitoring van trends in 5G-netwerken, capaciteitsindicatoren en het voorspellen van verzadiging voor operators in Zuid-Spanje, gebouwd op een backend in Laravel 11 en 12 die streamingdata met veel volume inleest. ## Buffer de ingestie, zodat verkeerspieken geen storingen worden Het ingestie-endpoint moet zo weinig mogelijk doen: de payload valideren, hem aan een buffer toevoegen en antwoorden. Parsen, verrijken en naar de database schrijven horen in workers. Bij een gemiddeld volume werkt Redis goed als buffer. Zet events op een Redis-list of -stream en laat workers ze in batches ophalen, want één gebundelde insert is voor de database veel goedkoper dan honderden inserts van één rij. - Valideer het schema en weiger misvormde events al aan de rand - Antwoord snel en schrijf binnen het request nooit naar de primaire database - Lees de buffer in batches uit in plaats van één event per job - Begrens de lengte van de buffer en geef een alert als hij groeit, zodat backpressure zichtbaar is voordat er data verloren gaat ## Schaal de verwerking met aparte queues en Horizon Laravel-queues op Redis geven je workers die je horizontaal kunt bijschakelen. Laravel Horizon toont per queue het aantal workers, de doorvoer en de wachttijden, en zo controleer je of de verwerking de ingestie bijhoudt. Scheid queues op prioriteit. Het evalueren van alerts mag nooit wachten achter een achterstand van historische herverwerking, dus geef verwerking, aggregatie, alerting en exports elk hun eigen queues en groepen workers. Maak elke job idempotent. Streams leveren opnieuw af, workers crashen halverwege een batch en er komen nieuwe pogingen, dus hetzelfde event twee keer verwerken mag een teller niet verdubbelen. Een event-ID dat wordt gecontroleerd tegen een kortlevende Redis-set is vaak genoeg. ## Aggregeer in tijdvakken voordat je broadcast Dashboards tonen snelheden, gemiddelden, percentielen en trends, geen losse events. Bereken die in workers in vaste tijdvakken, zoals per seconde en per minuut, voor elke entiteit die je toont: een cel, een regio, een klant. Bewaar de live aggregaten in Redis, in hashes of sorted sets met het tijdvak als key, en schrijf elk afgesloten tijdvak naar de database voor de geschiedenis. Het ontwerp van de queries op die historische tabellen telt net zo zwaar als het livepad, want gebruikers zoomen uit naar een dag of een week. Bij Slump verminderden een nieuw ontwerp van de Redis-caching en optimalisatie van queries de latency van de ingestie, en daardoor bleef het live-overzicht onder belasting actueel. ## Broadcast samenvattingen via WebSockets met Reverb of een gehoste dienst Laravel-broadcasting stuurt events naar kanalen waarop de frontend zich via Laravel Echo abonneert. Laravel Reverb is de eigen WebSocket-server van Laravel, en gehoste diensten zoals Pusher of Ably werken via dezelfde broadcasting-API. - Broadcast op een timer vanuit de geaggregeerde toestand, niet één keer per binnenkomend event - Gebruik private kanalen en autoriseer elk abonnement op de server, zodat gebruikers alleen de entiteiten zien die ze mogen zien - Stuur compacte snapshots of delta's, geen volledige datasets - Laat de client bij het opnieuw verbinden de huidige toestand via HTTP laden en daarna de stream hervatten - Draai meerdere Reverb-instanties achter een load balancer, met Redis pub/sub ertussen, naarmate het aantal verbindingen groeit ## Geef alerts op dynamische drempels in plaats van vaste grenzen Vaste drempels falen bij streamingmetrics in beide richtingen. Verkeer om 3 uur 's nachts lijkt in niets op verkeer om 8 uur 's avonds, dus één grens gaat óf de hele nacht af óf mist problemen overdag. Een dynamische drempel vergelijkt elke nieuwe waarde met een basislijn die is afgeleid van de recente geschiedenis van dezelfde entiteit op hetzelfde moment van de week. Een eenvoudige, uitlegbare variant houdt per entiteit en per uur van de week een voortschrijdend gemiddelde en een standaarddeviatie bij, en geeft een alert als de waarde meerdere opeenvolgende tijdvakken buiten die band blijft. Bij Slump verminderde dynamische alerting op afwijkingen het handmatige monitoren, omdat operators werden opgeroepen voor echte afwijkingen in plaats van naar schermen te kijken. - Eis aanhoudendheid, zoals drie opeenvolgende tijdvakken buiten de band, om ruis te beperken - Houd één open alert per entiteit en voorwaarde aan, die wordt bijgewerkt in plaats van herhaald - Neem in elke alert de huidige waarde, de basislijn, de band en een link naar het paneel op - Bekijk gedempte en genegeerde alerts regelmatig en stel de band bij ## Weet wanneer je aparte streamingtechnologie toevoegt Laravel met Redis dekt veel, maar heeft grenzen. Overweeg Kafka, Redpanda of een beheerde streamingdienst, vaak met een streamprocessor zoals Apache Flink, als je ruwe events lang moet bewaren en opnieuw moet kunnen afspelen, strikte volgorde per key over veel consumers nodig hebt, of een doorvoer die het geheugen van Redis tot bottleneck maakt. De overstap hoeft niet in één keer. Houd Laravel voor de API, dashboards, het beheer van alerts en broadcasting, en zet de stream vóór de aggregatiefase. Wij bouwen en breiden realtime systemen met deze opzet uit, van de ingestie tot de alertregels waar operators op vertrouwen. ## De kern - Stream nooit ruwe events naar browsers; broadcast geaggregeerde samenvattingen in een vast ritme. - Houd het ingestie-endpoint licht en buffer events in Redis voor verwerking in batches door workers. - Scheid queues op prioriteit en maak elke job idempotent, zodat nieuwe pogingen tellers niet kunnen beschadigen. - Dynamische drempels op basis van de recente geschiedenis leveren minder en nuttigere alerts op dan vaste grenzen. - Voeg Kafka of een vergelijkbaar platform toe als je replay, strikte volgorde of meer volume nodig hebt dan Redis aankan, en houd Laravel voor de applicatielaag. ## Veelgestelde vragen ### Kan Laravel realtime dashboards aan voor grote hoeveelheden data? Ja, als de architectuur zwaar werk buiten het requestpad houdt: een licht ingestie-endpoint, een Redis-buffer, workers via queues die in tijdvakken aggregeren, en WebSocket-broadcasts van alleen samenvattingen. Laravel bedient dan de API, dashboards en alerting, terwijl de workers onafhankelijk schalen. ### Laravel Reverb of Pusher voor WebSockets? Reverb is de eigen WebSocket-server van Laravel en draait op je eigen infrastructuur, wat past bij teams die grip willen op kosten en de locatie van hun data. Pusher of Ably nemen je het beheer van WebSocket-servers uit handen. Beide gebruiken dezelfde broadcasting-API van Laravel, dus je kunt later nog overstappen. ### Wat is een dynamische drempel bij monitoring? Een dynamische drempel is een alertgrens die wordt berekend uit de recente geschiedenis van dezelfde metric, entiteit en hetzelfde moment van de week, in plaats van een vast getal. Hij past zich aan dagelijkse en wekelijkse patronen aan, zodat alerts afgaan bij echte afwijkingen en niet bij normale pieken. ## Gerelateerde diensten - [Software op maat](https://sdk.enterprises/nl/services/product-engineering)