Seminar FoundationDB – Anwendungsarchitektur, Events und Integrationsmuster

Das Einzelseminar vermittelt Servicegrenzen, geordnete Ereignisprotokolle, Outbox- und Inbox-Muster, materialisierte Sichten, Warteschlangen und idempotente Workflows. Die Themen werden von der fachlichen Einordnung über die Konfiguration beziehungsweise Implementierung bis zur kontrollierten Prüfung in einer zusammenhängenden Laborumgebung bearbeitet.

Jeder Themenblock enthält eine eigene Inhaltsübersicht, konkrete Arbeitsschritte und Prüfpunkte. Konfigurationen, Datenmodelle und Betriebsentscheidungen werden so dokumentiert, dass sie in Projekt- und Betriebsstandards übernommen werden können.

Inhaltsübersicht

1. 1. Servicegrenzen und Eigentum im Schlüsselraum
2. 2. Fachliches Schlüsselraumdesign
3. 3. Outbox-, Inbox- und Deduplizierungsmuster
4. 4. Geordnetes Ereignisprotokoll und Cursor
5. 5. Materialisierte Sichten und abgeleitete Zustände
6. 6. Arbeitswarteschlangen, Claims und Leasing
7. 7. Idempotente Workflows und Zustandsautomaten
8. 8. Architekturreview und Produktionsfreigabe

1. Servicegrenzen und Eigentum im Schlüsselraum

Kapitelinhaltsverzeichnis

1. 1.1 Einordnung und Zielsetzung
2. 1.2 Fachthemen
3. 1.3 Schritt-für-Schritt-Übung
4. 1.4 Prüfpunkte

Einordnung und Zielsetzung

Servicegrenzen werden mit eindeutigen Schlüsselraumbereichen und Schreibrechten verknüpft. Gemeinsame Transaktionen sind nur dort vorgesehen, wo eine echte fachliche Invariante mehrere Domänen verbindet.

Fachthemen

• Domänenpräfixe
• Schreibverantwortung
• Gemeinsame Transaktionen

Schritt-für-Schritt-Übung: Schlüsselraumverantwortung festlegen

1. Schritt 1: Domänen und ihre fachlichen Invarianten erfassen.
2. Schritt 2: Pro Domäne einen stabilen Präfix- oder Tenant-Bereich zuweisen.
3. Schritt 3: Lesende und schreibende Schnittstellen je Bereich dokumentieren.
4. Schritt 4: Bereichsübergreifende Transaktionen auf notwendige Invarianten reduzieren.
5. Schritt 5: Eigentum, Migration und Störungszuständigkeit in einer Matrix festhalten.

Prüfpunkte

• Die Umsetzung berücksichtigt Domänenpräfixe und ist reproduzierbar dokumentiert.
• Das Verhalten von Schreibverantwortung ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

2. Fachliches Schlüsselraumdesign

Kapitelinhaltsverzeichnis

1. 2.1 Einordnung und Zielsetzung
2. 2.2 Fachthemen
3. 2.3 Schritt-für-Schritt-Übung
4. 2.4 Prüfpunkte

Einordnung und Zielsetzung

Das Datenmodell beginnt mit den Zugriffsmustern, nicht mit einer tabellarischen Übertragung. Entitäten, Beziehungen und Sortieranforderungen werden in stabile Präfixe und Bereichsgrenzen übersetzt.

Fachthemen

• Entitäten und Zugriffsmuster
• Präfixhierarchie
• Hotspot- und Wachstumsrisiken

Schritt-für-Schritt-Übung: einen Schlüsselraum aus Zugriffsmustern ableiten

1. Schritt 1: Häufige Lese-, Schreib- und Scanvorgänge priorisieren.
2. Schritt 2: Entitäten und Mandanten als stabile Präfixebenen modellieren.
3. Schritt 3: Sortierfelder in der Reihenfolge der benötigten Bereichszugriffe anordnen.
4. Schritt 4: Monoton wachsende oder stark konzentrierte Präfixe auf Hotspot-Risiken prüfen.
5. Schritt 5: Schlüsselbeispiele und Bereichsgrenzen in einem Modellkatalog dokumentieren.

Prüfpunkte

• Die Umsetzung berücksichtigt Entitäten und Zugriffsmuster und ist reproduzierbar dokumentiert.
• Das Verhalten von Präfixhierarchie ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

3. Outbox-, Inbox- und Deduplizierungsmuster

Kapitelinhaltsverzeichnis

1. 3.1 Einordnung und Zielsetzung
2. 3.2 Fachthemen
3. 3.3 Schritt-für-Schritt-Übung
4. 3.4 Prüfpunkte

Einordnung und Zielsetzung

Outbox und Inbox verbinden transaktionale Zustandsänderungen mit mindestens einmal zugestellten Nachrichten. FoundationDB übernimmt den atomaren lokalen Commit; externe Zustellung bleibt idempotent.

Fachthemen

• Atomarer Zustands- und Ereigniscommit
• Deduplizierung
• Asynchrone Zustellung

Schritt-für-Schritt-Übung: eine zuverlässige Nachrichtenzustellung umsetzen

1. Schritt 1: Operations-ID und Ereignis-ID außerhalb der Retry-Schleife erzeugen.
2. Schritt 2: Fachzustand und Outbox-Eintrag in derselben Transaktion schreiben.
3. Schritt 3: Dispatcher liest geordnet, sendet und markiert den Fortschritt idempotent.
4. Schritt 4: Empfänger prüft eine Inbox- oder Deduplizierungskennung.
5. Schritt 5: Absturz vor und nach Versand sowie wiederholte Zustellung testen.

Prüfpunkte

• Die Umsetzung berücksichtigt atomarer Zustands- und Ereigniscommit und ist reproduzierbar dokumentiert.
• Das Verhalten von Deduplizierung ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

4. Geordnetes Ereignisprotokoll und Cursor

Kapitelinhaltsverzeichnis

1. 4.1 Einordnung und Zielsetzung
2. 4.2 Fachthemen
3. 4.3 Schritt-für-Schritt-Übung
4. 4.4 Prüfpunkte

Einordnung und Zielsetzung

Ein Ereignisprotokoll nutzt geordnete Schlüssel, stabile Ereignis-IDs und gespeicherte Cursor. Partitionierung und Aufbewahrung werden so gestaltet, dass Verbraucher nach Unterbrechungen vollständig fortsetzen können.

Fachthemen

• Versionstamp-Reihenfolge
• Partitionierte Feeds
• Retention und Rebuild

Schritt-für-Schritt-Übung: einen verlässlichen Ereignisfeed bauen

1. Schritt 1: Partitionierung nach Domäne, Tenant oder Lastprofil festlegen.
2. Schritt 2: Ereignisschlüssel aus Partition, Versionstamp und stabiler ID bilden.
3. Schritt 3: Cursor je Verbraucher transaktional oder idempotent speichern.
4. Schritt 4: Batchgröße, Polling und Watch-basierte Wecksignale kombinieren.
5. Schritt 5: Retention erst nach bestätigten Verbrauchs- und Wiederaufbaugrenzen anwenden.

Prüfpunkte

• Die Umsetzung berücksichtigt Versionstamp-Reihenfolge und ist reproduzierbar dokumentiert.
• Das Verhalten von partitionierte Feeds ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

5. Materialisierte Sichten und abgeleitete Zustände

Kapitelinhaltsverzeichnis

1. 5.1 Einordnung und Zielsetzung
2. 5.2 Fachthemen
3. 5.3 Schritt-für-Schritt-Übung
4. 5.4 Prüfpunkte

Einordnung und Zielsetzung

Abgeleitete Sichten können synchron im Fachcommit oder asynchron aus einem Ereignisfeed gepflegt werden. Die Wahl wird anhand von Konsistenzbedarf, Schreibkosten und Wiederaufbaubarkeit getroffen.

Fachthemen

• Transaktionale Pflege
• Asynchroner Rebuild
• Version und Konsistenz

Schritt-für-Schritt-Übung: eine materialisierte Sicht entwerfen

1. Schritt 1: Abfrage, Aktualisierungsfrequenz und zulässige Verzögerung bestimmen.
2. Schritt 2: Synchronen und asynchronen Pflegepfad hinsichtlich Konflikten vergleichen.
3. Schritt 3: Sichtschlüssel und Versionierung definieren.
4. Schritt 4: Rebuild-Prozess mit Cursor und atomarer Umschaltung implementieren.
5. Schritt 5: Abweichungsprüfung zwischen Primärdaten und Sicht automatisieren.

Prüfpunkte

• Die Umsetzung berücksichtigt transaktionale Pflege und ist reproduzierbar dokumentiert.
• Das Verhalten von asynchroner Rebuild ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

6. Arbeitswarteschlangen, Claims und Leasing

Kapitelinhaltsverzeichnis

1. 6.1 Einordnung und Zielsetzung
2. 6.2 Fachthemen
3. 6.3 Schritt-für-Schritt-Übung
4. 6.4 Prüfpunkte

Einordnung und Zielsetzung

Eine Warteschlange benötigt atomare Beanspruchung, begrenzte Leases und idempotente Verarbeitung. Nur kleine Metadatentransaktionen werden synchronisiert; die eigentliche Arbeit läuft außerhalb.

Fachthemen

• Geordnete Aufgaben
• Claim-Schlüssel
• Lease-Verlängerung und Wiederaufnahme

Schritt-für-Schritt-Übung: eine robuste Worker-Queue implementieren

1. Schritt 1: Aufgabenschlüssel nach Priorität und Einreihungszeit ordnen.
2. Schritt 2: Claim, Besitzer und Lease-Ende in einer kurzen Transaktion setzen.
3. Schritt 3: Lange Verarbeitung außerhalb der Transaktion ausführen.
4. Schritt 4: Lease kontrolliert verlängern und Abschluss idempotent markieren.
5. Schritt 5: Workerabsturz, Lease-Ablauf und doppelte Aufnahme simulieren.

Prüfpunkte

• Die Umsetzung berücksichtigt geordnete Aufgaben und ist reproduzierbar dokumentiert.
• Das Verhalten von Claim-Schlüssel ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

7. Idempotente Workflows und Zustandsautomaten

Kapitelinhaltsverzeichnis

1. 7.1 Einordnung und Zielsetzung
2. 7.2 Fachthemen
3. 7.3 Schritt-für-Schritt-Übung
4. 7.4 Prüfpunkte

Einordnung und Zielsetzung

Mehrstufige Workflows werden als explizite Zustandsautomaten modelliert. Jeder Übergang ist klein, prüfbar und bei Wiederholung wirkungsgleich.

Fachthemen

• Operations-ID
• Zustandsübergänge
• Kompensation und Wiederaufnahme

Schritt-für-Schritt-Übung: einen wiederaufnehmbaren Workflow modellieren

1. Schritt 1: Zulässige Zustände und Übergänge formal festlegen.
2. Schritt 2: Operations- und Workflow-ID stabil erzeugen.
3. Schritt 3: Jeden Übergang mit erwartetem Ausgangszustand transaktional prüfen.
4. Schritt 4: Externe Schritte durch vorbereitete und bestätigte Zustände umschließen.
5. Schritt 5: Abbruch, Wiederholung und Kompensation für jeden Übergang testen.

Prüfpunkte

• Die Umsetzung berücksichtigt Operations-ID und ist reproduzierbar dokumentiert.
• Das Verhalten von Zustandsübergänge ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

8. Architekturreview und Produktionsfreigabe

Kapitelinhaltsverzeichnis

1. 8.1 Einordnung und Zielsetzung
2. 8.2 Fachthemen
3. 8.3 Schritt-für-Schritt-Übung
4. 8.4 Prüfpunkte

Einordnung und Zielsetzung

Das Review verbindet Anwendung und Betrieb. Ein Design gilt erst dann als freigabefähig, wenn Invarianten, Lastgrenzen, Wiederherstellung und Störungsverhalten nachgewiesen sind.

Fachthemen

• Datenmodell und Transaktionen
• Betrieb, Sicherheit und Recovery
• Last- und Fehlertests

Schritt-für-Schritt-Übung: eine Architekturentscheidung freigeben

1. Schritt 1: Zielbild, Schlüsselraum und Transaktionsinvarianten reviewen.
2. Schritt 2: Abhängigkeiten, Sicherheitsgrenzen und Betriebsverantwortung prüfen.
3. Schritt 3: Lastprofil, Kapazitätsmodell und Hotspot-Risiken bewerten.
4. Schritt 4: Backup-, Restore- und Ausfallszenarien gegen die Schutzziele testen.
5. Schritt 5: Offene Risiken mit Eigentümer, Frist und Freigabekriterium dokumentieren.

Prüfpunkte

• Die Umsetzung berücksichtigt Datenmodell und Transaktionen und ist reproduzierbar dokumentiert.
• Das Verhalten von Betrieb, Sicherheit und Recovery ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.