veterinäramt

Als das Veterinäramt während eines Ausbruchs der Afrikanischen Schweinepest vor dem digitalen Kollaps stand, ersetzten wir ein 30 Jahre altes AS/400-Terminal innerhalb von vier Wochen durch eine Cloud-native Event-Sourcing-Architektur - und verhinderten damit eine Verwaltungskatastrophe.

Öffentliche IT in Deutschland hat einen schlechten Ruf - oft zu Recht. Doch als unser Team im Frühjahr 2023 den Anruf eines Veterinäramts aus einer ländlichen Region erhielt, war klar: Hier geht es nicht um ein weiteres Formular, das man „mal eben" digitalisiert. Das bestehende System zur Verwaltung von Tierseuchenmeldungen, Quarantänezonen und Schlachthofkontrollen basierte auf einer monolithischen COBOL-Anwendung, die über einen Terminal-Emulator angesteuert wurde. Nach einem fehlgeschlagenen Update der Terminal-Software war das gesamte Amt handlungsunfähig - mitten in einer akuten Tierseuchenlage. Unsere Aufgabe: ein sicheres, skalierbares und vor allem schnell lieferbares Ersatzsystem. Was folgte, war eine Lektion in Sachen Event-getriebener Architektur, Geodatenverarbeitung und dem Spagat zwischen Agilität und Verwaltungscompliance.

Dieser Artikel beschreibt die technische Reise hinter dem modernen Veterinäramt: von fachlichen Anforderungen über Architekturentscheidungen bis hin zu konkreten Code- und Infrastrukturmustern. Wir teilen echte Produktionserfahrungen - mit Kafka-Topic-Partitionierungen, die den Dienst lahmlegten, mit einem PostgreSQL/PostGIS-Cluster, der bei 2. 000 Polygon-Overlays pro Sekunde in die Knie ging, und mit der Frage, wie man einen Zero-Trust-Ansatz durchsetzt, wenn das Veterinäramt noch Faxgeräte einsetzt.

Der digitale Wandel in deutschen Veterinärämtern: Von der Karteikarte zum Event-Log

Die rund 400 Veterinärämter in Deutschland sind rechtlich verpflichtet, alle tierseuchenrelevanten Daten zu erfassen, von Bestandsregistern über Bewegungsmeldungen bis zu Laborbefunden. Historisch geschah dies auf Papier, später in lokalen Access-Datenbanken oder jahrzehntealten Fachverfahren ohne API-Zugang. Unser Projekt startete mit einer ernüchternden Bestandsaufnahme: Die einzige digitale Schnittstelle des Bestandssystems war ein proprietäres Dateiformat, das einmal pro Nacht via FTP an das Landwirtschaftsministerium übertragen wurde. Das Veterinäramt selbst hatte keinen Zugriff auf eine standardisierte REST-API; Änderungen mussten händisch in einer grün-schwarzen Terminalmaske vorgenommen werden.

Der entscheidende Paradigmenwechsel war der Übergang von einer zustandsbasierten Datenhaltung zu einem vollständigen Event-Log. Statt den aktuellen Status eines Tierbestands oder einer Sperrzone als Datensatz zu speichern, zeichnet das neue System jeden fachlichen Vorgang als unveränderliches Ereignis auf - sei es die Meldung eines verendeten Wildschweins, die Anordnung einer Untersuchung oder die Aufhebung einer Quarantäne. Diese ereignisgesteuerte Architektur erlaubt nicht nur eine lückenlose Revisionssicherheit (Pflicht nach EU-Verordnung 2016/429), sondern auch die Ableitung beliebiger Projektionen für Auswertungen, ohne die Rohdaten zu duplizieren. In der Praxis bedeutete das, dass wir die komplexen fachlichen Zustandsmaschinen - etwa für den Status „Verdacht" → „Bestätigt" → „Bekämpft" - in Kafka Streams modellieren konnten.

Die Architektur des neuen Veterinäramt-Systems: Ein technischer Blueprint

Wir entschieden uns für eine Microservice-Architektur auf Basis von Kubernetes (GKE, da die Landes-IT eine Cloud-Strategie noch nicht abschließend definiert hatte), mit Apache Kafka als zentralem Nervensystem für Events. Die Domain „Veterinäramt" wurde in vier Bounded Contexts aufgeteilt: Tierbestandsregister, Seuchenbekämpfung, Schlacht- und Lebensmittelüberwachung sowie Berichtswesen. Jeder Context besitzt eigene Services, eigene Datenbanken (PostgreSQL, teils mit PostGIS) und kommuniziert ausschließlich asynchron über Kafka. Eine GraphQL-Fassade aggregiert Leseanfragen und entlastet die Fachservices von komplexen Join-Operationen.

Die Wahl von Kafka mag auf den ersten Blick übertrieben erscheinen für ein Amt mit vielleicht 50 gleichzeitigen Nutzern. Aber die Anforderung, räumlich verteilte Ereignisse (etwa von mobilen Android-Geräten der amtlichen Tierärzte) in Echtzeit zu verarbeiten und daraus sofort eine aktualisierte Sperrzone auf der GIS-Karte zu generieren, rechtfertigt die Infrastruktur. Ein Event-Sourcing-Ansatz mit Kafka ist zudem die einzige Möglichkeit, den gesetzlichen Nachweis zu erbringen, dass zu einem bestimmten Zeitpunkt eine amtliche Anordnung datumsgenau im System hinterlegt und nachvollziehbar verarbeitet wurde - ein klassischer Fall für Event-Sourcing und CQRS, wie es auch im Finanzsektor üblich ist. Wir haben in den ersten Produktionswochen allerdings gelernt, dass man Kafka-Partitionierung nicht als reines Durchsatzproblem betrachten darf; vielmehr mussten wir die Partitionierungsstrategie an den fachlichen Aggregate-IDs ausrichten, um Out-of-Order-Events innerhalb einer Tierbestandshistorie zu vermeiden.

API-Gateway und Microservices: Modularisierung von Fachverfahren für das Veterinäramt

Die Fachverfahren eines Veterinäramts sind juristisch getrennt, aber operativ eng verzahnt. Wird ein Schweinebestand wegen Verdachts auf ASP gesperrt, löst das gleichzeitig eine Benachrichtigung im Schlachtüberwachungs-Modul aus, damit keine Tiere mehr an den Schlachthof gebracht werden, und aktualisiert das Tierbestandsregister mit einem temporären Verbringungsverbot. Eine synchrone REST-Choreographie zwischen den Services hätte zu hoher Kopplung geführt. Stattdessen setzten wir auf einen Event-Carried State Transfer: Jeder Service produziert Fach-Events (z. And  BBestandGesperrt), die andere Services konsumieren und in ihre eigene Projektion überführen.

Die eigentliche Hürde war nicht die Technik, sondern die API-Governance. Das Projekt musste sicherstellen, dass der Event-Schema-Registry (Confluent Schema Registry) eine juristisch belastbare Versionierungshistorie zugrunde liegt. Jede Änderung eines Event-Schemas - etwa das Hinzufügen eines optionalen Feldes für den genetischen Erregertyp - musste mit einem Change Request im Anforderungsmanagement dokumentiert werden, den der zuständige Abteilungsleiter freigab. Um diesen Prozess nicht zum Flaschenhals zu machen, implementierten wir eine CI/CD-Pipeline, die bei jeder Schemaänderung automatisch einen Draft-Pull-Request in einem GitLab-Repository erzeugt, inklusive einer menschenlesbaren Beschreibung des Delta, generiert aus dem Avro-Schema-Diff. Diese Pipeline verkürzte den Genehmigungszyklus von durchschnittlich 14 Tagen auf unter 48 Stunden.

Geographische Informationssysteme (GIS) für das Tierseuchenmanagement

Das Herzstück jeder Seuchenbekämpfung ist die Karte: Wenn ein Wildschweinkadaver positiv auf ASP getestet wird, muss das Veterinäramt umgehend Sperrbezirke (Radius 3 km) und Beobachtungszonen (Radius 10 km) festlegen. Diese Polygone müssen rechtssicher digital verfügbar sein und sowohl den eigenen Vollzugsdienst als auch externe Jäger und Landwirte in Echtzeit erreichen. Wir implementierten einen PostGIS-Cluster mit einer dedizierten Feature Service API, die Geodaten im OGC Standard Simple Features-Format bereitstellt. Die eigentliche Herausforderung lag in den räumlichen Aggregationsabfragen: Um alle betroffenen Tierhaltungen innerhalb eines Sperrbezirks zu ermitteln, mussten wir Polygon-in-Polygon-Operationen für bis zu 20. 000 Betriebe unterhalb von 200 ms ausführen.

Unser erster Ansatz mit einem flachen GIST-Index auf den Betriebspunktkoordinaten scheiterte an der schieren Zahl der Geometrien, sobald auch historische Sperrgebiete berücksichtigt werden mussten. Die Lösung war eine hybride Indexstrategie: ein BRIN-Index für die grobe Vorauswahl ganzer Landkreise und ein partitionierter GDAL-basierter Cache für die exakten Polygon-Overlays, der mittels eines CRON-Jobs stündlich aus dem Event-Store neu aufgebaut wird. Für das Frontend nutzten wir OpenLayers mit einer tilebasierten Layer-Darstellung, um die Ladezeiten auch auf den mobilen Geräten der Außendienstmitarbeiter unter 3 Sekunden zu halten. Das Ergebnis: eine interaktive Karte, die nicht nur den aktuellen Stand zeigt, sondern auf Knopfdruck die Ausbreitungshistorie einer Seuche animiert - ein Feature, das bei der Lagebeurteilung durch das Veterinäramt Gold wert war.

Echtzeit-Datenverarbeitung mit Apache Kafka und Event Sourcing

Das Rückgrat des Systems ist ein dreistufiges Kafka-Streaming-Modell. Stufe 1 - Ingest: Rohdaten von IoT-Sensoren (Temperaturlogger aus Kadaverlagern) und mobilen Clients landen in einem raw events-Topic. Stufe 2 - Validation: Ein Kafka Streams-Prozessor führt eine Schemavalidierung (Avro) und eine fachliche Plausibilitätsprüfung durch - etwa ob die gemeldete Geokoordinate innerhalb des Zuständigkeitsbereichs des Veterinäramts liegt. Erst danach gelangt das Ereignis in das validated events-Topic. Stufe 3 - Projection: Separate Consumer (geschrieben in Kotlin, deployed als StatefulSet auf Kubernetes) materialisieren die Fachprojektionen in PostgreSQL-Tabellen und aktualisieren die Quarantänezonen-Geometrien in Echtzeit.

Ein praktisches Beispiel: Ein amtlicher Tierarzt findet ein totes Wildschwein und trägt die Daten in eine mobile Progressive Web App ein. Das Gerät sendet ein Event KadaverGefunden mit GPS-Koordinaten. Der Validierungs-Stream prüft, ob der Fundort in einem bereits bestehenden Sperrbezirk liegt. Falls ja, wird automatisch ein Alarm-Event an das Dashboard des Veterinäramts ausgelöst; falls nein, wird das Event als „Initialfund" kategorisiert und eine neue Sperrzone berechnet. Die Aktualisierung der Karte erfolgt im Median 1,2 Sekunden nach dem ersten API-Call. Um diesen Wert zuverlässig zu halten, mussten wir die Consumer-Lag-Überwachung mit Prometheus und Grafana bis auf Partition-Level granular einrichten; mehrfach stellten wir fest, dass ein einzelner Consumer durch eine fehlerhafte Polygon-Berechnung blockierte und die gesamte Kafka-Consumer-Group in Rückstand geriet. Prompt haben wir das Dead-Letter-Queue-Pattern eingeführt und eine automatisierte Rebalance-Strategie entwickelt, die auf Lag-Metriken reagiert.

Data Governance und Datenschutz im Kontext eines Veterinäramts

Die DSGVO mag nicht das Erste sein, woran man bei Tierseuchendaten denkt, doch die Stammdaten der Tierhalter unterliegen dem