Landkreis Fulda App

Ausgangslage

Die Plattform musste gleichzeitig mit operativer Skalierung und hoher Zuverlässigkeit umgehen. Die Herausforderung bestand nicht nur darin, große Datenmengen zu speichern, sondern hochfrequente Benachrichtigungs-Workflows zuverlässig zu machen, ohne die Anwendung für Endnutzer zu verlangsamen.

Was umgesetzt wurde

• Eine API-Schicht aufgebaut, die in einer behördlichen Betriebsumgebung mehr als 1.000.000 Datensätze verwalten kann.
• Einen Benachrichtigungs-Workflow umgesetzt, der täglich mehr als 80.000 Nachrichten über mehrere Kanäle ausliefert.
• Die Queue-Verarbeitung so abgestimmt, dass sie in Spitzenzeiten mehr als 1.000 Jobs pro Stunde bewältigt.

Technischer Ansatz

Laravel lieferte das Delivery-Framework, MySQL hielt den dauerhaften Anwendungszustand und Redis unterstützte die schnelllebige Queue- und Auslieferungsorchestrierung. Die Architektur trennte Echtzeit-Nutzerverkehr von Hintergrundarbeit, sodass Benachrichtigungsspitzen die normale Anwendung nicht beeinträchtigten.

Benachrichtigungs-Workflow

• Schritt 01: Nutzer-, Mitarbeiter- oder Systemereignisse kamen über Laravel-APIs in die Anwendung und wurden in ein konsistentes Notification-Payload überführt.
• Schritt 02: Delivery-Regeln entschieden, ob eine Nachricht in Push-, E-Mail- oder In-App-Kanäle laufen sollte, sodass kanalspezifische Arbeit getrennt blieb.
• Schritt 03: Redis-gestützte Queues übernahmen Dispatch-Vorbereitung und Worker-Ausführung, damit Massenaktivität niemals den interaktiven Anwendungstraffic blockierte.
• Schritt 04: Zustellstatus, Retry-Ergebnisse und Nachrichtenhistorie wurden wieder in die operative Datenebene zurückgeschrieben und blieben so auditierbar.

Queue-Topologie und Durchsatzkontrolle

Das Queue-Modell wurde auf Workload-Trennung statt auf einen generischen Worker-Pool ausgelegt. Hochvolumige Zustelljobs, Retry-Operationen und normale Hintergrundaufgaben der Anwendung wurden voneinander isoliert, damit ein Benachrichtigungsschub andere Systemaufgaben nicht verdrängte. Dadurch ließen sich Worker-Zahlen, Retry-Regeln und Prioritäten gezielter nach echtem Betriebsverhalten abstimmen.

• Echtzeit-Nutzeranfragen wurden klar von asynchronen Delivery-Pipelines getrennt.
• Redis übernahm schnelle Queue-Koordination, während MySQL der dauerhafte System-of-Record blieb.
• Retry-Handling und Zustandsanalyse wurden für operative Teams bei Incident-Reviews transparenter.

Architekturhinweise für den Betrieb

Architektonisch war die entscheidende Entscheidung, die Nachrichtenorchestrierung so einfach zu halten, dass sie unter Public-Sector-Zuverlässigkeitsanforderungen gut betreibbar blieb. Laravel-Services übernahmen Business Rules, Redis lieferte schnelle Queue-Bewegung und MySQL speicherte Nutzerzustand, Nachrichtenmetadaten und Zustellhistorie. So blieb Skalierungsdruck in der asynchronen Ebene konzentriert und griff nicht auf die primäre Anwendungserfahrung über.