Wem gehören die Daten wirklich? Wer Daten besitzt entscheidet über Tempo, Risiko und Wertschöpfung in Microservice-Landschaften. 09.04.2026 | Lesezeit: 2 min Daten sind in Microservice-Architekturen nicht einfach Bits, sie sind Währung und Konfliktstoff zugleich; wer sie besitzt, kann entscheiden wie schnell Funktionen entstehen und wie sicher sie laufen. Wenn Systeme sich entkoppeln Der Wechsel zu Microservices brachte Autonomie und Geschwindigkeit, aber auch Verlagerung von Datenverantwortung, weil jede Komponente zunehmend ihre eigenen Persistenzen verwaltet und damit Fragen von Konsistenz, Duplikation und Governance aufwirft. Die Akteure im Spiel An der Schnittstelle stehen Entwickler, Softwarearchitekten, Produktverantwortliche, Plattformteams und Compliance, denn technische Entscheidungen haben rechtliche und wirtschaftliche Folgen und erfordern abgestimmte Rollen für Besitz, Zugriffsrechte und Lifecycle von Daten. Technische und wirtschaftliche Hebel Der Grundsatz ist einfach und schwer zugleich: ein Service owns seine Daten und bietet klare Schnittstellen, doch in der Praxis entstehen Duplikate, Event-Streams und Analyseablagen die Synchronisation nötig machen; Muster wie Consumer Driven Contracts, Event Sourcing, Change Data Capture und Sagas helfen Konsistenz zu managen, während Schema-Registries, Data Catalogs und Zugriffssteuerungen die Governance vereinfachen; wirtschaftlich bedeutet Ownership Autonomie und schnellere Releases, aber auch Kosten durch Datenbewegung und zusätzlichen Betriebsaufwand. Zwei Szenen aus dem Alltag Bei einer Shop-Plattform war der Lager-Service alleiniger Besitzer der Inventardaten und publizierte Events über Bestandsänderungen; trotzdem führte fehlende Rückmeldegarantie zu gelegentlichem Überverkauf. In einem anderen Fall exportierte ein Analytics-Team Rohdaten aus einem Service ohne abgestimmte Löschprozesse, was zu Problemen mit Datenschutzanforderungen führte. Meine Einschätzung Datenhoheit darf nicht als Dogma verstanden werden, sondern als praktisches Designprinzip das klare Verträge, Discoverability und automatisierte Kontrollen braucht; eine rein zentrale oder rein federierte Governance führt jeweils zu Engpässen oder Silos, die Lösung liegt in klaren Verantwortungen kombiniert mit Plattformwerkzeugen. Was Praktiker jetzt tun sollten Architekten müssen Ownership-Modelle definieren und Verträge erzwingen, Entwickler sollten Schnittstellen und Events als Quelle der Wahrheit implementieren und Manager sollten Zeit und Budget für Plattformfunktionen wie Schema-Registries und Lineage-Tools bereitstellen, denn nur so wird Datenhoheit zum Wettbewerbsvorteil statt zur Haftungsfalle. Connect with Andreas Hernitscheck Solution & Software Architect Datenhoheit Microservices Data Mesh Domain-driven Design Event Sourcing Architektur Datensicherheit DevOps
