Verteilte Systeme programmieren

Sobald eine Anwendung aus mehreren Diensten besteht, die über ein Netzwerk kommunizieren, gelten neue Regeln: Aufrufe können langsam sein, verloren gehen oder doppelt ankommen. Du lernst, wann synchrone Kommunikation über HTTP passt und wann Nachrichten über einen Broker besser sind. Du baust Dienste, die Fehler abfedern, Daten trotz Verteilung konsistent halten und sich im Betrieb nachvollziehen lassen. Am Ende setzt du ein kleines System aus mehreren Diensten mit Docker Compose um und kannst deine Architekturentscheide begründen.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Ein System sinnvoll in Dienste aufteilen

   Kompetenz A

   Du entscheidest, welche Teile einer Anwendung als eigener Dienst laufen sollen und welche besser zusammenbleiben. Massgebend sind fachliche Grenzen, unabhängige Skalierung und eigene Daten, nicht die Lust auf möglichst viele Microservices.

   Situation

   Ein regionaler Velokurier in Bern möchte seine monolithische Auftragsverwaltung modernisieren. Die Tourenplanung bremst bei Hochbetrieb alles andere aus.

   Deine Aufgabe

   Schlage eine Aufteilung vor und begründe sie.

   Gutes Ergebnis

   Drei Dienste: Aufträge, Tourenplanung und Benachrichtigungen. Die Tourenplanung skaliert separat, hat ihre eigene Datenbank und bekommt Aufträge über Ereignisse. Die Rechnungsstellung bleibt bewusst im Auftragsdienst, weil sie eng mit den Aufträgen verbunden ist.

   Monolith vs. MicroservicesBounded Contextlose KopplungDatabase per Service
2. 2

   Synchrone und asynchrone Kommunikation gezielt einsetzen

   Kompetenz B

   Du weisst, wann ein Dienst eine Antwort sofort braucht (REST, gRPC) und wann es reicht, eine Nachricht abzuschicken und weiterzuarbeiten (Queue, Topic). Du kennst die Folgen für Wartezeiten, Kopplung und Fehlerverhalten.

   Situation

   Im Onlineshop eines Sportartikelhändlers in Luzern wartet der Kunde nach dem Kauf 8 Sekunden, weil Bestellbestätigung, Lagerbuchung und Rechnung nacheinander per HTTP aufgerufen werden.

   Deine Aufgabe

   Gestalte den Ablauf so um, dass der Kunde sofort eine Rückmeldung bekommt.

   Gutes Ergebnis

   Nur die Zahlungsprüfung bleibt synchron. Danach publiziert der Bestelldienst ein Ereignis 'BestellungAufgegeben' auf RabbitMQ. Lager, Rechnung und Mailversand reagieren unabhängig. Die Antwortzeit sinkt auf unter 1 Sekunde.

   Request/ResponseMessage BrokerQueue vs. TopicEvent-drivengRPC
3. 3

   Dienste gegen Netzwerkfehler und Ausfälle absichern

   Kompetenz C

   Du gehst davon aus, dass ein anderer Dienst langsam oder weg sein kann. Mit Timeouts, Retries mit wachsenden Wartezeiten, Circuit Breakern und sinnvollen Fallbacks verhinderst du, dass ein einzelner Ausfall das ganze System mitreisst.

   Situation

   Ein Ticketportal für Konzerte im Hallenstadion ruft für jede Seite einen externen Sitzplan-Dienst auf. Fällt dieser aus, hängen alle Threads und die ganze Seite ist offline.

   Deine Aufgabe

   Sorge dafür, dass die Seite bei einem Ausfall weiter funktioniert.

   Gutes Ergebnis

   Timeout von 2 Sekunden, drei Retries mit Backoff, danach öffnet ein Circuit Breaker für 30 Sekunden. Als Fallback zeigt die Seite 'Sitzplan momentan nicht verfügbar' und lässt den Kauf nach Kategorie zu.

   TimeoutRetry mit BackoffCircuit BreakerFallbackKaskadierender Ausfall
4. 4

   Daten über mehrere Dienste hinweg konsistent halten

   Kompetenz D

   Ohne gemeinsame Datenbank gibt es keine einfache Transaktion über alles. Du baust Abläufe deshalb so, dass sie Schritt für Schritt abgeschlossen oder mit Gegenbuchungen rückgängig gemacht werden, und akzeptierst bewusst, dass Daten kurz unterschiedlich sein können.

   Situation

   Bei einem Reisebüro in Basel werden Flug und Hotel in zwei Diensten gebucht. Schlägt die Hotelbuchung fehl, bleibt der Flug trotzdem reserviert.

   Deine Aufgabe

   Gestalte den Buchungsablauf so, dass keine halben Buchungen entstehen.

   Gutes Ergebnis

   Eine Saga mit Zustandsautomat: Flug reservieren, Hotel reservieren, beide bestätigen. Scheitert ein Schritt, wird eine Stornierung für die bereits erledigten Schritte ausgelöst. Der Kunde sieht den Status 'in Bearbeitung', bis alles abgeschlossen ist.

   Eventual ConsistencySagaKompensationCAP-TheoremOutbox-Pattern
5. 5

   Doppelte Nachrichten und Aufrufe gefahrlos verarbeiten

   Kompetenz D

   In verteilten Systemen kommt eine Nachricht im Zweifel lieber zweimal an als gar nicht. Du baust Empfänger so, dass eine zweite Verarbeitung keinen Schaden anrichtet, z.B. mit eindeutigen IDs und Prüfung, ob etwas schon erledigt ist.

   Situation

   Eine Krankenkasse in Winterthur bekommt Rückerstattungen über eine Queue. Nach einem Neustart des Dienstes wurden einzelne Rückerstattungen doppelt ausbezahlt, total CHF 4'300.

   Deine Aufgabe

   Verhindere doppelte Auszahlungen, ohne Nachrichten zu verlieren.

   Gutes Ergebnis

   Jede Nachricht trägt eine eindeutige Beleg-ID. Der Dienst speichert verarbeitete IDs in einer Tabelle mit Unique-Constraint, in derselben Transaktion wie die Buchung. Eine Wiederholung wird erkannt und nur bestätigt.

   IdempotenzAt-least-once DeliveryDeduplizierungIdempotency Key
6. 6

   Abläufe über Dienstgrenzen hinweg nachvollziehbar machen

   Kompetenz E

   Wenn ein Fehler über vier Dienste wandert, reicht ein einzelnes Logfile nicht. Du sorgst für strukturierte Logs, eine Korrelations-ID pro Anfrage, Health-Checks und einfache Metriken, damit du Probleme im Betrieb schnell eingrenzen kannst.

   Situation

   Beim Velokurier melden Fahrer, dass manche Aufträge nie in der App erscheinen. Jeder Dienst schreibt eigene Logs ohne Zusammenhang.

   Deine Aufgabe

   Mach den Weg eines Auftrags durch alle Dienste sichtbar.

   Gutes Ergebnis

   Eine Korrelations-ID wird beim Eingang erzeugt und in HTTP-Headern und Nachrichten weitergegeben. Die Logs landen als JSON in Grafana Loki. Eine Suche nach der ID zeigt, dass Nachrichten mit fehlender PLZ in der Dead-Letter-Queue landen.

   Korrelations-IDstrukturiertes LoggingDistributed TracingHealth-CheckDead-Letter-Queue

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Elena ist im 4. Lehrjahr als Informatikerin Applikationsentwicklung bei der Rheintal Logistik AG in Buchs SG, einem Transportunternehmen mit 220 Mitarbeitenden. Die Sendungsverfolgung ist ein einziger grosser Monolith, der in der Weihnachtszeit regelmässig in die Knie geht und dabei auch die Disposition lahmlegt. Ihr Teamleiter gibt ihr den Auftrag, einen Prototyp für eine Aufteilung in Dienste zu bauen.

1. Kapitel 1

   Wo sind die Nähte?

   Elena analysiert den Monolithen und findet drei fachliche Bereiche: Scan-Erfassung in den Depots, Sendungsstatus und Kundenbenachrichtigung. Ihr erster Entwurf hat sieben Dienste, doch im Review merkt sie, dass Adresse und Sendung fast immer gemeinsam geändert werden. Sie fasst zusammen und landet bei drei Diensten mit je eigener Datenbank. Die Skizze in draw.io zeigt jetzt auch, welche Daten wem gehören.

   Ziel 1

2. Kapitel 2

   Anrufen oder Bescheid geben?

   In der Spitzenzeit treffen 40 Scans pro Sekunde ein. Im ersten Prototyp ruft die Scan-Erfassung den Benachrichtigungsdienst per REST auf, und sobald das SMS-Gateway langsam wird, stauen sich die Handscanner im Depot. Elena stellt auf ein Ereignis SendungGescannt über RabbitMQ um, das die Benachrichtigung in ihrem eigenen Tempo abarbeitet. Die Statusabfrage der Kundenwebsite bleibt bewusst ein synchroner REST-Aufruf, weil dort sofort eine Antwort nötig ist.

   Ziel 2

3. Kapitel 3

   Das SMS-Gateway fällt aus

   Im Lasttest mit Docker Compose stoppt Elena den SMS-Dienst für zehn Minuten. Nach dem Neustart erhalten Testkunden für denselben Scan drei SMS, weil die Wiederholungen ungebremst nachgeschoben werden. Sie konfiguriert Retry mit exponentiellem Backoff und höchstens fünf Versuchen, danach landet die Nachricht in einer Dead-Letter-Queue. Zusätzlich speichert der Empfänger jede Ereignis-ID und verwirft Duplikate stillschweigend.

   Ziel 3Ziel 5

4. Kapitel 4

   Zugestellt, aber nicht verrechnet

   Bei Nachnahme-Sendungen muss die Zustellung den Status setzen und den Betrag an die Buchhaltung melden. Stürzt der Dienst genau zwischen Datenbank-Commit und Publizieren ab, fehlt die Buchung, das zeigt ein gezielter Kill im Test. Elena schreibt das Ereignis deshalb in eine Outbox-Tabelle in derselben Transaktion und lässt einen Relay-Prozess publizieren. Lehnt die Buchhaltung eine Buchung ab, setzt ein Ausgleichsschritt den Status auf "Zustellung fehlgeschlagen" zurück.

   Ziel 4Ziel 5

5. Kapitel 5

   Welcher Scan war es?

   Ein Testkunde meldet, seine Sendung bleibe auf "unterwegs" hängen. Ohne gemeinsame ID sucht Elena eine Stunde lang in drei Logdateien. Sie baut eine Middleware für Korrelations-IDs ein und schickt die Traces mit OpenTelemetry an Grafana, wo sie sofort sieht, dass ein Consumer Nachrichten mit Umlauten im Ortsnamen verwirft. Nach der Korrektur ergänzt sie einen Alarm, sobald mehr als 10 Nachrichten pro Stunde in der Dead-Letter-Queue landen, und präsentiert den Prototyp dem Team.

   Ziel 6

1. 1

   Was im Netz alles schiefgeht

   ca. 4 Std.

   Du verstehst, warum verteilte Systeme anders funktionieren als ein einzelnes Programm, und wann sich die Aufteilung lohnt.

   • Die typischen Irrtümer über Netzwerke (z.B. 'Latenz ist null') an eigenen Beispielen erklären
   • Einen bestehenden Monolithen aus dem Unterricht skizzieren und mögliche Dienstgrenzen einzeichnen
   • Für zwei Varianten der Aufteilung Vor- und Nachteile in einer Tabelle gegenüberstellen

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Dienste sprechen miteinander

   ca. 7 Std.

   Du verbindest zwei Dienste zuerst synchron über REST und danach asynchron über einen Message Broker.

   • Zwei Spring-Boot- oder ASP.NET-Dienste per REST verbinden und mit Postman testen
   • RabbitMQ in Docker Compose starten und ein Ereignis publizieren und konsumieren
   • Die Antwortzeiten beider Varianten unter Last messen und vergleichen

   Trainiert Kompetenz B1B2

   Lernziel2

3. 3

   Ausfälle provozieren und abfedern

   ca. 7 Std.

   Du baust Fehler absichtlich ein und machst deine Dienste robust dagegen.

   • Einen Zieldienst mit künstlicher Verzögerung oder Absturz ausstatten
   • Timeout, Retry und Circuit Breaker mit Resilience4j oder Polly konfigurieren
   • Nachrichten absichtlich doppelt senden und den Empfänger idempotent machen

   Trainiert Kompetenz C1C2D1

   Lernziel35

4. 4

   Konsistenz ohne gemeinsame Datenbank

   ca. 7 Std.

   Du setzt einen Geschäftsablauf über mehrere Dienste mit einer Saga und Kompensationen um.

   • Einen Buchungsablauf als Zustandsdiagramm mit allen Fehlerpfaden zeichnen
   • Die Saga umsetzen und jeden Fehlerpfad gezielt auslösen
   • Das Outbox-Pattern an einem Beispiel nachbauen

   Trainiert Kompetenz D2D3

   Lernziel45

5. 5

   Sichtbar machen

   ca. 5 Std.

   Du rüstest dein System mit Logs, Korrelations-IDs und Health-Checks aus, sodass du Fehler im Betrieb findest.

   • Korrelations-ID als Middleware einbauen und durch HTTP und Nachrichten weiterreichen
   • Logs zentral sammeln und eine Fehlersuche anhand einer ID durchspielen
   • Health-Endpunkte für Docker Compose einrichten

   Trainiert Kompetenz E1E2

   Lernziel6

6. 6

   Abschlussprojekt: kleines verteiltes System

   ca. 5 Std.

   Du baust ein System mit drei Diensten, einem Broker und einer Datenbank pro Dienst und dokumentierst deine Entscheide.

   • Architekturskizze mit Kommunikationswegen und Begründung erstellen
   • Alles mit einem einzigen 'docker compose up' startbar machen
   • Einen Ausfall vorführen und zeigen, wie das System reagiert

   Trainiert Kompetenz A3B3C3E3

   Lernziel1236

Verteiltes System

Mehrere eigenständige Programme auf verschiedenen Rechnern oder Containern, die über ein Netzwerk zusammenarbeiten.

Message Broker

Vermittler, der Nachrichten von Sendern entgegennimmt, zwischenspeichert und an Empfänger verteilt, z.B. RabbitMQ oder Kafka.

Idempotenz

Eigenschaft einer Operation, bei mehrfacher Ausführung dieselbe Wirkung (denselben Zustand) zu haben wie bei einmaliger.

Circuit Breaker

Schutzmechanismus, der Aufrufe an einen fehlerhaften Dienst vorübergehend unterbindet.

Eventual Consistency

Daten sind nach einer Änderung kurzzeitig unterschiedlich, gleichen sich aber nach einer gewissen Zeit an.

Saga

Muster für dienstübergreifende Abläufe aus lokalen Transaktionen mit Kompensationsschritten.

Outbox-Pattern

Ereignisse werden in derselben DB-Transaktion wie die Fachdaten gespeichert und danach zuverlässig versendet.

Distributed Tracing

Verfolgen einer Anfrage über alle beteiligten Dienste hinweg mit gemeinsamer Kennung.

Passende Module