Globale und mehrregionale Systeme

Das Licht ist schnell, aber nicht unendlich schnell. Ein Signal braucht von Frankfurt nach Sydney und zurück rund eine Viertelsekunde, und eine Webseite braucht oft mehrere solcher Wege, bevor sie angezeigt wird. Für Nutzer auf der anderen Seite der Welt fühlt sich eine Anwendung, die nur in Frankfurt läuft, deshalb träge an – egal wie schnell der Server ist. Hinzu kommen Ausfallsicherheit und rechtliche Vorgaben zum Speicherort von Daten. Globale und mehrregionale Systeme lösen diese Probleme, gehören aber zu den anspruchsvollsten Architekturen überhaupt. Diese Lektion zeigt, welche Ausbaustufen es gibt und wann welche gerechtfertigt ist.

1. Entfernung kostet Zeit

Die Latenz zwischen zwei Orten wird durch die Physik begrenzt: Licht in Glasfasern legt etwa 200 Kilometer pro Millisekunde zurück, und Kabel verlaufen selten auf dem kürzesten Weg. Keine Optimierung am Server kann diese Zeit verkürzen; nur ein näherer Server hilft. Probieren Sie es aus – wählen Sie Regionen und den Standort eines Nutzers:

Das Beispiel zeigt, warum global genutzte Anwendungen Inhalte näher an ihre Nutzer bringen. Der einfachste und wirksamste Schritt ist fast immer ein CDN: Statische Dateien, Bilder und öffentliche Seiten werden an Hunderten Standorten weltweit zwischengespeichert. Für viele Anwendungen, deren Nutzer überwiegend in einer Region sitzen, ist das bereits genug.

2. Ausbaustufen

Jede Stufe löst ein konkretes Problem, und jede weitere Stufe ist deutlich aufwendiger als die vorige. Üben Sie, die passende Stufe zu wählen:

3. Aktiv-passiv und aktiv-aktiv

Aktiv-passiv ist vor allem ein Schutz gegen Katastrophen. Die zweite Region erhält laufend replizierte Daten und kann bei einem großen Ausfall übernehmen, meist nach einigen Minuten. Nutzer profitieren im Alltag nicht von kürzeren Wegen, aber die Architektur bleibt vergleichsweise einfach, weil nur an einer Stelle geschrieben wird. Aktiv-aktiv bringt beides: kurze Wege und hohe Ausfallsicherheit. Der Preis ist die Datenhaltung. Wenn in zwei Regionen gleichzeitig geschrieben wird, entstehen dieselben Konflikte wie bei Offline-Anwendungen – nur in großem Maßstab und mit strengeren Anforderungen.

4. Daten über Regionen hinweg

Für die Datenhaltung in mehreren Regionen haben sich drei Muster bewährt. Beim ersten gibt es eine Schreibregion: Alle Änderungen gehen an eine Region, die anderen halten Lesekopien. Lesen ist überall schnell, Schreiben aus der Ferne langsamer. Beim zweiten werden die Daten nach Heimatregion aufgeteilt: Die Daten europäischer Kunden liegen in Frankfurt, die asiatischer in Singapur. Jede Region schreibt nur ihre eigenen Daten, Konflikte entstehen kaum. Dieses Muster passt gut zu mandantenfähigen Plattformen und erleichtert zugleich die Einhaltung von Vorgaben zum Datenstandort. Beim dritten kommen global verteilte Datenbanken zum Einsatz, die Konsistenz über Regionen hinweg selbst sicherstellen – mit höheren Schreiblatenzen und Kosten.

5. Datenstandort und Recht

Für europäische Unternehmen ist die Frage, wo Daten liegen, nicht nur technisch. Die DSGVO erlaubt die Übermittlung personenbezogener Daten in Drittländer nur unter bestimmten Voraussetzungen, und viele Kunden – besonders Behörden, Gesundheitswesen und Finanzbranche – verlangen ausdrücklich einen Speicherort in der EU oder in Deutschland. Ein mehrregionales System muss das berücksichtigen: Replikate europäischer Kundendaten dürfen nicht ohne Weiteres in einer amerikanischen Region landen, auch nicht als Backup. Auch Logs, Caches, Suchindizes und KI-Dienste gehören in diese Betrachtung. Die Aufteilung nach Heimatregion hilft hier doppelt.

6. Kosten und ehrliche Abwägung

Mehrere Regionen vervielfachen nicht nur die Serverkosten, sondern auch den Datenverkehr zwischen Regionen, der bei Cloudanbietern teuer ist, und vor allem den Aufwand für Betrieb, Tests und Fehlersuche. Deshalb lohnt eine ehrliche Frage: Wo sitzen die Nutzer wirklich, und was kostet ein Ausfall? Ein Hotel an der Algarve mit Gästen aus ganz Europa braucht eine gut gebaute Anwendung in einer europäischen Region mit mehreren Zonen und ein CDN – aber keine Server in drei Kontinenten. Eine Lernplattform mit wachsendem Markt in Asien profitiert dagegen von einer zweiten Region, sobald die Nutzerzahlen dort nennenswert sind. Wie bei allen Entwurfsentscheidungen gilt: den nächsten Schritt gehen, wenn Messwerte ihn rechtfertigen, und den übernächsten vorbereiten, etwa indem Mandanten- und Regionskennungen von Anfang an in den Daten stehen.

7. Schritt für Schritt in die Welt

Wie wächst eine Anwendung typischerweise über Regionen hinaus? Ein bewährter Weg beginnt mit Messungen: Aus welchen Ländern kommen die Nutzer, wie lange dauern ihre Seitenaufrufe, und welcher Anteil davon entfällt auf Netzwerkwege? Oft zeigt sich, dass ein CDN, zwischengespeicherte API-Antworten und weniger aufeinanderfolgende Anfragen pro Seite schon den größten Teil des Problems lösen. Als Nächstes wird die Anwendung auf mehrere Verfügbarkeitszonen verteilt, was die Ausfallsicherheit stark erhöht. Erst wenn ein nennenswerter Teil der Nutzer weit entfernt sitzt oder ein Kunde vertraglich einen anderen Datenstandort verlangt, folgt eine zweite Region – zunächst oft nur für Lesezugriffe oder für neue Mandanten dieser Region.

Entscheidend ist, dass die Architektur diesen Weg nicht verbaut. Dazu gehören zustandslose Anwendungsserver, eine klare Trennung von Lese- und Schreibzugriffen, eine Mandanten- oder Regionskennung in allen Daten, Konfiguration statt fest eingetragener Adressen und automatisierte Infrastruktur, die sich in einer weiteren Region wiederholen lässt. Mit diesen Vorbereitungen ist eine zweite Region ein überschaubares Projekt. Ohne sie wird sie zum Umbau des gesamten Systems. Und schließlich sollte der Notfall geübt werden: Ein Umschalten auf die zweite Region, das nie getestet wurde, funktioniert im Ernstfall selten auf Anhieb. Regelmäßige Übungen, bei denen eine Region bewusst abgeschaltet wird, zeigen, ob Replikation, DNS-Umschaltung und Anleitungen wirklich tragen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.