Seminar Phoenix Framework – OTP, Umbrella-Projekte und verteilte Systeme

Das dreitägige Aufbauseminar verbindet Phoenix mit OTP-Architektur und verteiltem BEAM-Betrieb. Prozesse, Supervision, Registry, PubSub, Umbrella-Grenzen, Clusterzustand, Fehlerszenarien und Release-Topologien werden praktisch untersucht.

Inhaltsübersicht

• Seminarprofil, Zielgruppe und Voraussetzungen
• Lernziele
• Schrittweise Seminarinhalte
• Praxisprojekt
• Methodik

Zielgruppe

Erfahrene Elixir- und Phoenix-Entwickler, Softwarearchitekten und technische Plattformverantwortliche

Voraussetzungen

Sichere Elixir- und Phoenix-Kenntnisse sowie grundlegendes Verständnis von Prozessen, Nachrichten und Supervision

Lernziele

• OTP-Prozessmodelle passend zum Fachproblem entwerfen
• Umbrella-Anwendungen anhand realer Grenzen strukturieren
• Verteilten Zustand und Kommunikation fehlertolerant gestalten
• Cluster, Releases und Störungsfälle praktisch beherrschen

Seminarinhalte

1. OTP-Entscheidungsmodell

1. Schritt 1: Zustandslose Funktionen, Prozesse und externe Speicher unterscheiden.
2. Schritt 2: Prozessverantwortung und Lebensdauer festlegen.
3. Schritt 3: Unnötige Prozessabstraktionen früh erkennen.

2. GenServer und Prozess-APIs

1. Schritt 1: Synchronen und asynchronen Zugriff anhand der Konsistenz wählen.
2. Schritt 2: Zustand klein, rekonstruierbar und versionierbar halten.
3. Schritt 3: Timeouts, Überlast und ungültige Nachrichten behandeln.

3. Supervision und Startreihenfolge

1. Schritt 1: Supervisor-Bäume nach Fehlerdomänen strukturieren.
2. Schritt 2: Restart-Strategien und Intensitäten passend konfigurieren.
3. Schritt 3: Abhängigkeiten über explizite Start- und Bereitschaftskriterien steuern.

4. Registry und dynamische Prozesse

1. Schritt 1: Prozesse über stabile fachliche Schlüssel registrieren.
2. Schritt 2: DynamicSupervisor für bedarfsgesteuerte Worker einsetzen.
3. Schritt 3: Race Conditions bei Start und Lookup kontrollieren.

5. PubSub und Ereignisarchitektur

1. Schritt 1: Lokale und verteilte Abonnements modellieren.
2. Schritt 2: Ereignisverträge klein und rückwärtskompatibel halten.
3. Schritt 3: Doppelte und verspätete Nachrichten berücksichtigen.

6. Umbrella-Projekte

1. Schritt 1: Domänen-, Web- und Infrastrukturanteile in Anwendungen schneiden.
2. Schritt 2: Abhängigkeiten und Konfiguration zwischen Apps minimieren.
3. Schritt 3: Gemeinsame Datenbank und Deploymentgrenzen bewusst entscheiden.

7. Verteilte BEAM-Knoten

1. Schritt 1: Knotennamen, Cookies und Discovery konzeptionell einordnen.
2. Schritt 2: Prozesse, Nachrichten und PubSub über Knoten beobachten.
3. Schritt 3: Netzpartitionen und Knotenwechsel im Design berücksichtigen.

8. Verteilte Zustandsmuster

1. Schritt 1: Single-Owner-, Partitionierungs- und Replikationsansätze vergleichen.
2. Schritt 2: Globale Namensauflösung und Locking kritisch bewerten.
3. Schritt 3: Externe Konsistenzgrenzen und Wiederaufbaupfade definieren.

9. Clusterfähige Phoenix-Anwendung

1. Schritt 1: Endpoint, Presence und PubSub in mehreren Instanzen betreiben.
2. Schritt 2: Session-, Upload- und Hintergrundzustand clusterfähig gestalten.
3. Schritt 3: Health Checks pro Knoten und Dienst definieren.

10. Fault Injection

1. Schritt 1: Prozessabstürze, Timeouts und Knotenverlust gezielt auslösen.
2. Schritt 2: Neustart, Wiederanmeldung und Datenkonsistenz beobachten.
3. Schritt 3: Fehlerannahmen in automatisierte Tests überführen.

11. Releases und Topologien

1. Schritt 1: Umbrella- oder Einzelreleases nach Deploymentgrenzen erstellen.
2. Schritt 2: Runtime-Konfiguration und Clustereinstellungen trennen.
3. Schritt 3: Rolling Restart und Versionskompatibilität planen.

Praxisprojekt

Aufbau einer clusterfähigen Phoenix-Umbrella-Anwendung mit Domänen-App, Web-App, Registry, dynamischen Workern, PubSub, Presence, Fault-Injection-Szenarien und getrenntem Releasekonzept.

Methodik

Kurze fachliche Einführungen wechseln mit Live-Demonstrationen, geführten Implementierungsschritten, eigenständigen Übungen, Code-Reviews, Fehlerszenarien und überprüfbaren Zwischenständen. Sämtliche Übungen bauen auf einem konsistenten Referenzprojekt auf.