Trennen Sie Zugänge, Fachverarbeitung, Daten und Betriebskontrollen und legen Sie Regionen und Lastziele passend zum Programm fest.
Eine Loyalty-Architektur muss mehr leisten als Last zu verteilen. Sie muss vor allem erklären, wo die verbindliche Buchung entsteht und wie das Programm nach einer Störung wieder konsistent arbeitet.
Die konkrete Auswahl, Topologie und Region jedes Dienstes werden in der freigegebenen Architektur festgelegt.
Front Door und ein abgestimmtes WAF-/DDoS-Schutzkonzept können den äußeren Zugang bilden. API Management setzt die vereinbarten Zugangskontrollen und Schnittstellenregeln um.
Die Schutzwirkung hängt von der gewählten Konfiguration und dem gesamten Pfad ab.
Fachservices führen die berechtigte Aktion aus. Der verbindliche Ledger-Pfad erhält eine definierte Transaktionsgrenze; zusätzliche Datenhaltung bekommt eine klare, davon getrennte Aufgabe.
Ein parallel in zwei Datenbanken geschriebener Saldo ist kein belastbares Ledger-Design.
Schlüsselverwaltung, Telemetrie und Sicherheitsbefunde ergänzen den laufenden Betrieb. Dev, QA und Produktion erhalten getrennte Umgebungen und kontrollierte Berechtigungen.
Infrastructure as Code und automatisierte Deployments benötigen Freigabe, Nachweis und Rückfallweg.
Diese Systeme sind keine austauschbaren Architekturbausteine. Entra ID kann den bestätigten Identitätszugang übernehmen, Dynamics einen fachlichen Unternehmensprozess und Power BI eine Analysesicht. Microsoft 365 unterstützt den vereinbarten Zusammenarbeitspfad. Datenobjekt, Zweck und Betriebsverantwortung werden jeweils separat zugeordnet.
Ein Kassenaufruf und ein umfangreicher Reportingexport haben unterschiedliche Anforderungen. Eine geeignete Architektur trennt den zeitkritischen Buchungspfad von nachgelagerter Arbeit.
Lastverteilung kann Zugänge auf mehrere Instanzen verteilen. Die fachliche Entscheidung benötigt trotzdem eine klare Quelle für verfügbares Guthaben und Reservierungen. Ereignisse für Kommunikation oder Reporting können nach einer bestätigten Buchung asynchron weitergegeben werden.
Lesende und schreibende Routen werden getrennt bewertet. Begrenzte Warteschlangen, kontrollierte Drosselung und definierte Fehlerantworten verhindern, dass ein einzelner überlasteter Folgeprozess den gesamten Ablauf unkontrolliert mitzieht. Ein Rückstau braucht sichtbare Menge und Alter der noch offenen Arbeit.
Die Umschaltung folgt einem bestätigten Verfahren. Führende Daten, Rückstände und bereits ausgeführte externe Vorgänge werden geprüft. Eine wieder erreichbare Anwendung ist erst dann fachlich betriebsbereit, wenn Punkte, Belege, Einlösungen und Partnerzustände ausreichend abgeglichen sind.
| Datenbereich | Zu dokumentieren | Prüffrage |
|---|---|---|
| Primärdaten | Führender Dienst, Region und Replikationsweg | Wo wird die verbindliche Buchung geführt? |
| Replikate / Failover | Zielregion, Konsistenz und Umschaltbedingung | Welcher Stand ist bei einer Umschaltung tatsächlich verfügbar? |
| Backups / Dateien | Ablage, Verschlüsselung und Aufbewahrung | Wo liegen Kopien und wie wird ihre Wiederherstellung geprüft? |
| Logs / Telemetrie | Inhalt, Region und Zugriffsrechte | Welche personenbezogenen Daten werden im Betrieb zusätzlich erfasst? |
| Support / Subprozessoren | Zugriffsweg, Rolle und vertragliche Grundlage | Wer kann von wo auf welche Daten zugreifen? |
Antwortzeit-Verteilungen für eine konkrete Route, Region und definierte Datenmenge.
Erfolgreich verarbeitete Vorgänge je Zeit, getrennt nach Lese- und Schreibpfad.
Technische Fehler, fachliche Ablehnung und Drosselung separat ausweisen.
Zeit von der bestätigten Buchung bis zur Verarbeitung im angebundenen System.
Die Messung nennt Routenmix, gleichzeitige Zugriffe, Datenbestand, Peak-Dauer, Region und relevante Abhängigkeiten. Eine kurze synthetische Spitze belegt nicht die Stabilität eines mehrstündigen Aktionsstarts. Testdaten und erwartetes Ergebnis werden vor der Messung festgelegt.
Erst ein bestätigter Testbericht ermöglicht eine konkrete Leistungsbewertung. Ein vertragliches Service Level benötigt zusätzlich Messpunkt, Zeitraum, Ausschlüsse und Verantwortlichkeit. Eigenschaften eines Azure-Dienstes übertragen sich nicht automatisch auf die Gesamtanwendung.
Datenumfang, Aufbewahrung und verschlüsselte Kopien festlegen.
Restore mit repräsentativen Daten und dokumentierter Dauer durchführen.
Verantwortung und Freigabe für Zonen- oder Regionswechsel klären.
Ledger, offene Aufträge und externe Wirkungen referenziert prüfen.
Nachholungen und Normalbetrieb kontrolliert starten.
Allgemeine Architekturgrundlagen: Microsoft: Azure Front Door und Performance-Modellierung und SRE. Diese Quellen beschreiben Azure-Muster, keine ProLoyalty-Produktivinstallation.
Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.
