Referenzarchitektur: Multi-Region / global

Sind Benutzer geografisch verteilt oder ist Ausfallsicherheit gegen eine regionale Katastrophe gefordert, verteilen sich Daten über mehrere Regionen. Dieser Baum geht Schritt für Schritt Leselokalität (eine Read Replica pro Region), Schreibtopologie (Single-Leader vs. Multi-Leader vs. Quorum), Datenresidenz/Compliance (DSGVO), Konfliktauflösung und die Kompromisse zwischen RPO/RTO und Latenz durch. Die Grundwahrheit: Wegen der Gesetze der Physik lassen sich niedrige Latenz, starke Konsistenz und Schreiben in mehreren Regionen nicht gleichzeitig vollständig erreichen; ein bewusster Kompromiss ist Pflicht.

Warum Multi-Region: Leselokalität, Schreibvorgänge/Ausfallsicherheit oder Compliance?

Eine Multi-Region-Architektur ist teuer und komplex; kläre die Motivation. Willst du niedrige Leselatenz für entfernte Benutzer, regionsübergreifende Schreibvorgänge/Katastrophenresistenz, oder ist die eigentliche Anforderung, dass Daten in einem bestimmten Land bleiben (rechtliche Residenz)?

• Schnelle Lesevorgänge für entfernte Benutzer; Schreibvorgänge können in einer Region bleiben
• Regionsübergreifende Schreibvorgänge / Ausfallsicherheit gegen Verlust einer Region sind gefordert
• Daten müssen rechtlich in einem bestimmten Land/einer bestimmten Region bleiben

Wie soll die Schreibtopologie aussehen: Single-Leader, Multi-Leader oder Quorum?

Bei regionsübergreifenden Schreibvorgängen ist die zentrale Entscheidung das Leader-Modell. Gehen alle Schreibvorgänge an eine Region (einfach, konsistent, aber entfernte Schreibvorgänge sind langsam), kann jede Region schreiben (niedrige Schreiblatenz, aber Konflikte), oder wird ein Schreibvorgang mit Bestätigung einer Mehrheit der Regionen angenommen (Quorum: konsistent, aber mit zusätzlicher Latenz)?

• Eine Region schreibt, die anderen lesen (einfach und konsistent)
• Jede Region kann lokal schreiben (niedrige Schreiblatenz)
• Schreiben mit Mehrheitsbestätigung; Konsistenz hat Vorrang

Empfehlung: eine Read Replica pro Region (Leselokalität)

Schreibvorgänge bleiben in einer einzigen Primary-Region, während du in jede Benutzerregion eine von dort gespeiste Read Replica stellst. Benutzer lesen von der nächstgelegenen Replica und die Leselatenz sinkt; da Schreibvorgänge weiterhin an ein Zentrum gehen, bleibt das Konsistenzmodell einfach.

Empfehlung: Single-Leader-Schreibvorgänge

Alle Schreibvorgänge gehen an eine einzige Leader-Region; die anderen Regionen sind Read Replicas, die asynchron von diesem Leader gespeist werden. Das ist das einfachste und am stärksten konsistente Modell; es gibt keine Konflikte, da es nur einen Schreibpunkt gibt. Der Preis ist hohe Schreiblatenz aus entfernten Regionen.

Empfehlung: Multi-Leader-Schreibvorgänge + Konfliktauflösung

Da jede Region lokal schreiben kann, ist die Schreiblatenz niedrig, und selbst wenn eine Region abgeschnitten ist, schreiben die anderen weiter. Der Preis ist hoch: Zwei Regionen können denselben Datensatz unterschiedlich aktualisieren, und du musst eine Konfliktauflösung entwerfen.

Empfehlung: quorumbasierte Schreibvorgänge (Mehrheitsbestätigung)

Ein Schreibvorgang wird angenommen, wenn eine Mehrheit (Quorum) der Regionen/Replicas ihn bestätigt; gehen auch Lesevorgänge an eine Mehrheit, ist der neueste Wert garantiert. Das ist robust gegen Regionsverlust und stark konsistent; der Preis ist die Latenz, bis jeder Schreibvorgang eine Mehrheit erreicht.

Empfehlung: Datenresidenz / Compliance (DSGVO)

Manche Daten (personenbezogene, Gesundheits-, Finanzdaten) müssen rechtlich innerhalb der Grenzen eines bestimmten Landes/einer Region bleiben (z. B. DSGVO). In diesem Fall entwirfst du die Architektur nicht nach „überall kopieren“, sondern so, dass Daten geografisch fixiert sind.