Sovereign Cell Architecture: Datenzentrierte Systemarchitektur für Compliance und Kontrolle
Sovereign Cell Architecture: Systemdesign mit Fokus auf Regulierung
Dieses Thema ausschließlich als technisches Problem zu betrachten, führt von Anfang an zu einer falschen Perspektive.
Beginnen wir mit einer kurzen Geschichte.
Ein SaaS-Unternehmen, das in ganz Europa tätig ist, ist über Jahre hinweg gewachsen und hat stolz von einer „Multi-Region“-Architektur gesprochen. Alles schien zu funktionieren: Systeme liefen stabil, Kunden kamen hinzu und das Produkt entwickelte sich weiter.
Bis eines Tages ein Audit stattfand.
Eine einfache Frage veränderte alles:
Befinden sich die Daten deutscher Kunden tatsächlich in Deutschland?
Das Team antwortete selbstbewusst mit Ja – schließlich gab es ein Deployment in Deutschland.
Doch bei genauerem Hinsehen zeigte sich ein anderes Bild.
Backups wurden in den USA gespeichert. Logs waren zentralisiert. Support-Teams aus verschiedenen Ländern hatten Zugriff auf die Daten.
Technisch funktionierte das System weiterhin.
Aus regulatorischer Sicht war es jedoch nicht compliant.
Und ab diesem Moment änderte sich alles.
Die meisten Unternehmen gestalten ihre Systeme nicht neu, weil sie nicht skalieren – sondern weil sie regulatorische Anforderungen nicht erfüllen.
Es geht hier nicht um Performance.
Es geht darum, wo Daten gespeichert sind, wer Zugriff darauf hat und ob die Architektur einem Audit standhält.
Es geht nicht darum, Systeme zu trennen – sondern Daten
Der häufigste Fehler besteht darin, das System aufteilen zu wollen.
Das eigentliche Problem ist jedoch nicht das System.
Es sind die Daten.
Stellen Sie sich zwei Kunden vor, die dasselbe Produkt nutzen – einer in Deutschland, einer in der Türkei. Nach außen hin ist die Erfahrung identisch: gleicher Login, gleiche Oberfläche, gleiche Prozesse.
Doch im Hintergrund sollten sie in zwei völlig unterschiedlichen Welten existieren.
Genau das erzwingt eine Sovereign Cell Architecture.
Jede Cell ist ein eigenständiges System mit:
- eigener Datenbank
- eigenen Services
- eigener Logging- und Backup-Struktur
- eigenem Key-Management
Die globale Ebene speichert keine Daten.
Sie leitet lediglich Anfragen an die richtige Cell weiter.
Multi-Region vs. Sovereign Architecture
Diese beiden Konzepte werden häufig verwechselt – dabei lösen sie unterschiedliche Probleme.
- Multi-Region dient Performance und Verfügbarkeit
- Sovereign Architecture dient Kontrolle und Compliance
Die entscheidende Frage lautet:
Wo befinden sich Ihre Daten tatsächlich?
In vielen Systemen starten Daten in einer Region – verteilen sich jedoch anschließend:
- Backups in anderen Ländern
- Logs in zentralen Systemen
- Caching in anderen Regionen
- Zugriff durch Personen über Ländergrenzen hinweg
Daten sind nicht nur technisch verteilt – sondern auch organisatorisch.
Und Regulierungen stellen eine einfache Frage:
Bleiben die Daten innerhalb ihrer definierten Grenzen?
Die meisten Systeme können darauf keine klare Antwort geben.
Isolation ist ein Spektrum
Isolation ist kein Entweder-oder – sondern ein Spektrum.
- Geteilte Systeme → geringe Kosten, hohes Risiko
- Regionale Trennung → bessere Kontrolle
- Cell-basierte Isolation → höchste Sicherheit, höhere Kosten
Der größte Fehler?
Zu glauben, dass maximale Isolation immer die beste Lösung ist.
Der richtige Ansatz ist:
Die Isolation entsprechend dem tatsächlichen Bedarf zu gestalten.
Warum klassische Architekturen nicht ausreichen
Traditionelle Ansätze lösen dieses Problem nicht vollständig.
- Monolithen skalieren global schlecht – jede Region benötigt eine vollständige Kopie
- Microservices bieten Flexibilität, verwischen jedoch oft Daten-Grenzen
- Multi-Region-Setups verteilen Systeme, aber nicht zwingend die Datenkontrolle
Viele Teams bleiben an diesem Punkt stehen, weil das System „funktioniert“.
Doch der wahre Test ist immer das Audit.
Am Ende geht es um eines: Boundary Design
Im Kern läuft alles auf eine Frage hinaus:
Wie definieren Sie Ihre Grenzen?
Sovereign Cell Architecture bedeutet nicht, Services zu trennen.
Es bedeutet, Daten-Grenzen konsequent zu kontrollieren.
Das ist nicht nur für Compliance entscheidend, sondern auch für das Risikomanagement.
Wenn etwas schiefgeht, darf nicht das gesamte System betroffen sein.
Nur eine einzelne Cell sollte betroffen sein.
So wird der Blast Radius reduziert.
Die eigentliche Herausforderung: nicht technisch, sondern finanziell
In der Theorie ist das Modell klar.
In der Praxis wird es komplex.
Es gibt zwei Ebenen:
Globale Ebene
- Routing von Anfragen
- Identifikation des Nutzers
- Keine Datenspeicherung
Cell-Ebene
- APIs
- Services
- Datenbanken
- Storage
- Logging
- Key-Management
Die größte Herausforderung ist nicht die Technik.
Sondern die Kosten.
Logging, Monitoring, Tracing und Backups werden teuer, wenn sie pro Region dupliziert werden.
Werden sie zentralisiert, wird die Compliance verletzt.
Die eigentliche Herausforderung besteht darin, die richtige Balance zu finden.
Die goldene Regel
Wenn eine Anfrage ins System gelangt:
- Wird sie von der globalen Ebene verarbeitet
- An die richtige Cell weitergeleitet
- Vollständig lokal ausgeführt
Rohdaten verlassen niemals die definierten Grenzen.
Nur anonymisierte oder aggregierte Daten dürfen übertragen werden.
Wann diese Architektur nicht sinnvoll ist
Nicht jedes System benötigt diesen Ansatz.
Für:
- kleine Anwendungen
- Systeme in nur einem Land
- einfache Produkte
führt diese Architektur zu unnötiger Komplexität und Kosten.
Häufige Fehler in der Praxis
Teams machen bei der Umsetzung oft ähnliche Fehler:
- Speicherung von Daten in der globalen Ebene
- Unkontrollierter Zugriff für Support-Teams
- Backups in anderen Ländern
- Zentrales Key-Management
Und trotzdem glauben viele, compliant zu sein.
Bis das Audit das Gegenteil beweist.
Ein einfacher Test
Stellen Sie sich vor, ein Land wird komplett abgeschaltet.
Fragen Sie sich:
Funktionieren die Systeme in anderen Ländern weiterhin?
Wenn ja, sind Sie auf dem richtigen Weg.
Fazit
Services zu trennen ist einfach.
Die eigentliche Architektur besteht darin, Daten-Grenzen korrekt zu definieren.
Und genau hier entsteht der entscheidende Wettbewerbsvorteil.
Referenzen
- Microsoft Learn – Multi-Tenant-Architekturansätze:
https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/overview - AWS Well-Architected – Reduzierung des Wirkungsbereichs mit Cell-basierter Architektur:
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html - Architect Elevator – Hybrid Cloud:
https://architectelevator.com/cloud/hybrid-cloud
