Verteilte Systeme verstehen

Was ein verteiltes System ausmacht

Ein verteiltes System besteht aus eigenständigen Komponenten, die über ein Netzwerk zusammenarbeiten. Sie tauschen Daten und Nachrichten aus, um gemeinsam eine Aufgabe zu erfüllen. Schon eine Anwendung mit einem separaten Datenbankserver verteilt Arbeit auf mehrere Rechner. Eine Einführung in das Grundprinzip bietet AWS zu Distributed Computing.

Im Unternehmen reicht die Zusammenarbeit häufig weiter: Ein ERP verwaltet Aufträge, eine Plattform verarbeitet Maschinendaten und ein Kundenportal zeigt den Bearbeitungsstand. Diese Komponenten können im eigenen Betrieb, in der Cloud oder an verschiedenen Standorten laufen.

Dabei beschreiben die folgenden Begriffe unterschiedliche Entscheidungen. Sie lassen sich kombinieren und auch einzeln einsetzen:

Einsatzmöglichkeiten in Mittelstand und Industrie

Für die Digitalisierung von Geschäftsprozessen sind beispielsweise diese Aufgaben interessant:

• Betriebsdaten auswerten: Messwerte verschiedener Anlagen werden angenommen, aufbereitet und für Service oder Flottenmanagement bereitgestellt. Datenerfassung und aufwendige Auswertung können getrennt arbeiten.
• Auftragsabwicklung verbinden: Vertrieb, Lager und Versand tauschen Änderungen aus. Ein neuer Versandstatus kann sowohl das Kundenportal als auch eine interne Auswertung aktualisieren.
• Technischen Service unterstützen: Störungsmeldung, Einsatzplanung und Bereitstellung des Serviceberichts greifen ineinander, obwohl unterschiedliche Anwendungen beteiligt sind.
• Software schrittweise modernisieren: Ein neuer Funktionsbereich ergänzt eine bestehende Anwendung. Weitere Teile können folgen, sobald Schnittstellen und Verantwortlichkeiten geklärt sind. Wie daraus eine Ablösung des Altsystems wird, zeigt der Artikel zum Strangler Pattern.

Das sind mögliche Einsatzfelder. Ob eine zusätzliche Verteilung dafür hilfreich ist, hängt vom jeweiligen Ablauf, seinen Abhängigkeiten und dem Aufwand für den Betrieb ab.

Welche Vorteile daraus entstehen können

Kapazität gezielt erweitern

Eine rechenintensive Auswertung lässt sich auf zusätzliche Verarbeitungseinheiten verteilen, sofern die Aufgabe dafür geeignet ist. Die Benutzeroberfläche benötigt deshalb nicht automatisch dieselbe zusätzliche Kapazität. Skalierbarkeit ist ein wesentlicher Vorteil verteilter Verarbeitung; gemeinsam genutzte Datenbanken oder stark voneinander abhängige Arbeitsschritte können sie begrenzen. AWS: verteilte Verarbeitung.

Lastspitzen und Unterbrechungen abfangen

Eine dauerhaft speichernde Warteschlange kann eingehende Aufgaben puffern, während die Verarbeitung beschäftigt oder vorübergehend nicht erreichbar ist. So muss ein kurzer Anstieg von Serviceanfragen nicht sofort alle nachgelagerten Funktionen überlasten. Dafür braucht es ausreichende Speicherkapazität, verlässliche Zustellung und Überwachung des Rückstaus. Eine Warteschlange erhöht nicht von selbst die Verarbeitungskapazität. Microsoft: Queue-Based Load Leveling.

Teile unabhängig weiterentwickeln

Bei klaren fachlichen Grenzen und kompatiblen Schnittstellen lassen sich einzelne Dienste separat aktualisieren. Ein zusätzlicher Filter im Kundenportal muss dann beispielsweise keine Änderung an der Verarbeitung von Sensordaten erfordern. Diese Unabhängigkeit ist ein Ziel von Microservices; sie entsteht durch passende Grenzen und Verträge zwischen den Diensten. Microsoft: Microservices-Architektur.

Beispiel: Ein Serviceauftrag löst Folgearbeit aus

Der folgende Ablauf ist ein entworfenes Beispiel, keine Kundenreferenz. Ein Maschinenbetreiber meldet eine Störung. Die Serviceanwendung erfasst den Auftrag. Sobald ein Termin vereinbart ist, sollen Disposition, Kundenportal und Benachrichtigung darüber informiert werden.

Eine Möglichkeit wäre, alle drei Komponenten direkt aufzurufen und auf ihre Antworten zu warten. Bei einer ereignisgesteuerten Lösung veröffentlicht die Serviceanwendung stattdessen die Nachricht „Servicetermin vereinbart“. Sie beschreibt ein bereits eingetretenes fachliches Ereignis und enthält beispielsweise Auftragskennung und Termin.

Die interessierten Komponenten reagieren darauf:

1. Die Disposition aktualisiert ihre Planung.
2. Das Kundenportal übernimmt den neuen Termin in seine Anzeige.
3. Die Benachrichtigung verschickt die vereinbarte Information.

Dadurch können Empfänger zeitlich getrennt arbeiten. Eine weitere Auswertung kann später ebenfalls auf das Ereignis reagieren, wenn der Nachrichteninhalt ausreicht. Diese Aufteilung in Erzeuger, Nachrichtenkanal und Empfänger beschreibt Microsoft als ereignisgesteuerte Architektur.

Für den Gesamtprozess muss trotzdem feststehen, wer offene oder fehlgeschlagene Folgeschritte erkennt. Eine veröffentlichte Nachricht allein bestätigt noch nicht, dass die Kundeninformation zugestellt wurde.

Pub/Sub: Ereignisse an mehrere Dienste verteilen

Publish/Subscribe, kurz Pub/Sub, ist eine Möglichkeit, den beschriebenen Ereignisaustausch umzusetzen. Ein Publisher veröffentlicht eine Nachricht auf einem Topic, also einem benannten Nachrichtenkanal. Subscriber abonnieren diesen Kanal und reagieren auf die für sie relevanten Ereignisse. Der Publisher braucht dadurch keine direkte Verbindung zu jedem Empfänger.

Im entworfenen Servicebeispiel ist der Auftragsdienst der Publisher. Er meldet „Servicetermin vereinbart“. Eine mögliche Nachricht enthält:

• Ereignis-ID: eine eindeutige Kennung zur Wiedererkennung dieses Ereignisses.
• Auftragskennung: die Zuordnung zum betroffenen Serviceauftrag.
• Termin: den bestätigten Zeitpunkt mit vereinbarter Zeitzonenangabe.
• Vorgangsversion: den Stand des Auftrags, auf den sich die Meldung bezieht.

Die drei empfangenden Microservices verwenden die Nachricht für ihre eigenen Aufgaben. Sie schreiben nicht direkt in die Datenhaltung des Auftragsdienstes.

Ein SNS-Topic mit einer SQS-Queue je Empfänger

Auf AWS kann der Auftragsdienst an ein Amazon-SNS-Topic veröffentlichen. Für Disposition, Kundenportal und Benachrichtigung wird jeweils eine eigene Amazon-SQS-Queue abonniert. SNS verteilt eine Kopie der Nachricht an jede dieser Queues; die Dienste verarbeiten sie unabhängig. Das beschreibt AWS als SNS-/SQS-Fanout.

Eine Queue pro Dienst ist hier entscheidend: Würden alle drei Dienste dieselbe Queue verarbeiten, würden sie sich die Nachrichten teilen, statt jeweils eine Kopie für ihre unterschiedlichen Aufgaben zu erhalten. Mehrere Worker innerhalb eines Dienstes können dagegen gemeinsam dessen Queue abarbeiten.

Eine Queue puffert ausstehende Verarbeitung innerhalb ihrer Aufbewahrungsdauer. Fällt der Benachrichtigungsdienst kurz aus, können Disposition und Portal weiterarbeiten. Wiederanlauf, Queue-Kapazität und Rückstau müssen dennoch überwacht werden. Ein neuer Auswertungsdienst kann über eine zusätzliche Queue abonnieren; bereits zuvor veröffentlichte Ereignisse erhält er dadurch nicht automatisch als Historie.

Wiederholungen, Reihenfolge und Veröffentlichung absichern

Bei SQS-Standardqueues sind mehrfache Zustellungen und eine abweichende Reihenfolge möglich. Empfänger müssen deshalb wiederholte Verarbeitung vertragen und verspätete Meldungen passend behandeln. AWS: Eigenschaften von SQS-Standardqueues.

Die Ereignis-ID hilft, bereits bearbeitete Nachrichten wiederzuerkennen. Die Vorgangsversion hilft einer Leseansicht zu entscheiden, ob eine Terminmeldung noch aktuell ist. Bei einem reinen Zustandsupdate kann der vollständig übermittelte neuere Stand maßgeblich sein; wo jeder Übergang fachlich wichtig ist, braucht es zusätzlich Regeln für Lücken und Reihenfolge. Eine ältere Nachricht darf nicht unbemerkt einen neueren Termin überschreiben.

Nach erfolgreicher Verarbeitung wird die Nachricht aus der Queue entfernt. Eine Unterbrechung kann vorher zu erneuter Zustellung führen. Auch eine doppelte E-Mail ist eine fachliche Nebenwirkung: Neben gespeicherten Ereignis-IDs muss deshalb geklärt sein, wie der Versanddienst Wiederholungen behandelt. Eine Kennung allein garantiert keine einmalige externe Wirkung.

Für wiederholt fehlschlagende Nachrichten wird eine Fehlerwarteschlange, häufig Dead-Letter Queue genannt, eingerichtet. Monitoring meldet beispielsweise einen wachsenden Rückstau oder solche Fehler. Zuständige Personen können die Ursache korrigieren und eine kontrollierte erneute Verarbeitung veranlassen.

Auch die Veröffentlichung braucht Absicherung. Speichert der Auftragsdienst Terminänderung und ausgehendes Ereignis gemeinsam in einer Datenbanktransaktion, kann ein separater Versandprozess das bestätigte Ereignis an SNS weitergeben. Das Transactional-Outbox-Muster verhindert die Lücke zwischen gespeicherter Änderung und einem anschließend ausgefallenen Versand; doppelte Veröffentlichungen bleiben möglich und werden bei den Empfängern berücksichtigt. AWS: Transactional Outbox.

Pub/Sub beschreibt die Verteilung von Nachrichten. Event Sourcing beschreibt dagegen, wie ein Dienst seinen Zustand aus einer gespeicherten Ereignisfolge aufbaut. Das Servicebeispiel kann mit einer herkömmlichen Zustandsdatenbank und Outbox umgesetzt werden; die Wahl von Pub/Sub legt die Speicherung nicht fest.

Ich konzipiere und entwickle solche Softwaresysteme aus Microservices. Für die technische Umsetzung auf AWS finden Sie Details im Leistungsangebot zur Cloud-native Softwareentwicklung auf AWS; der Cloud-native-Ratgeber erläutert Vorteile, Kosten und Verantwortung.

Event Sourcing: den Verlauf als Grundlage speichern

Event Sourcing geht einen Schritt weiter: Zustandsänderungen werden als fachliche Ereignisse dauerhaft gespeichert. Aus ihrer Folge lässt sich der Zustand eines Vorgangs berechnen. Die Historie dient damit als Grundlage der Anwendung. Martin Fowler erläutert dieses Prinzip und die Rekonstruktion früherer Zustände in seiner Beschreibung von Event Sourcing.

Vom Ereignis zum aktuellen Stand

Für unseren entworfenen Serviceauftrag könnte die Folge so aussehen:

1. Serviceauftrag angelegt — mit Auftragskennung und gemeldeter Störung.
2. Servicetermin vereinbart — mit dem bestätigten Termin.
3. Servicetermin verschoben — mit dem neuen Termin und dem erfassten Grund.
4. Einsatz abgeschlossen — mit dem Ergebnis des Einsatzes.
5. Servicebericht freigegeben — mit einem Verweis auf die freigegebene Dokumentversion.

Die Anwendung leitet daraus unter anderem aktuellen Termin und Bearbeitungsstand ab. Eine Korrektur wird als weiteres Ereignis ergänzt. Entscheidend sind eine eindeutige Zuordnung zum Vorgang und eine verlässliche Reihenfolge innerhalb seiner Ereignisfolge. Ein zusätzliches technisches Log oder allein der Versand von Nachrichten macht aus einer Anwendung noch kein Event-Sourcing-System. Microsoft: Event Sourcing.

Was der gespeicherte Verlauf ermöglicht

Mit den passenden Ereignissen lassen sich frühere Zustände nachvollziehen und neue Auswertungen aus bereits gespeicherten Informationen aufbauen. Im Beispiel könnte der Betrieb untersuchen, wie viel Zeit zwischen Meldung, Terminvereinbarung und Abschluss vergeht. Voraussetzung ist, dass die dafür erforderlichen Angaben tatsächlich erfasst wurden.

Das erneute Verarbeiten der Ereignisse heißt Replay. Dabei dürfen frühere E-Mails oder externe Buchungen nicht erneut ausgelöst werden. Fowler behandelt diese Trennung zwischen Rekonstruktion und Außenwirkungen ausdrücklich. Event Sourcing: Umgang mit externen Systemen.

Anzeigen und Schreiben getrennt betrachten

Für schnelle Abfragen werden häufig Projektionen aufgebaut: abgeleitete Ansichten wie eine Liste offener Serviceaufträge. Bei langen Ereignisfolgen können gespeicherte Zwischenstände, sogenannte Snapshots, den Wiederaufbau beschleunigen. Die gespeicherten Ereignisse bleiben die Grundlage. Alte Ereignisformate müssen auch nach Softwareänderungen noch korrekt verarbeitet werden können. Microsoft: Projektionen, Snapshots und Versionierung.

Häufig wird Event Sourcing mit CQRS kombiniert. Dabei werden Zustandsänderungen und Abfragen über getrennte Modelle behandelt. CQRS lässt sich auch ohne Event Sourcing einsetzen. Werden separate Leseansichten asynchron aktualisiert, können sie kurz hinter dem bestätigten Schreibstand zurückliegen. Diese Verzögerung ist eine Folge der gewählten Aktualisierung und muss in der Bedienung berücksichtigt werden. Microsoft: CQRS.

Event Sourcing passt besonders dann, wenn der Verlauf selbst fachlich wichtig ist und regelmäßig ausgewertet oder rekonstruiert werden soll. Für einfache Stammdatenpflege ist eine herkömmliche Datenbank mit gezielter Änderungshistorie häufig ausreichend. Das Muster sollte für die Teile eines Systems gewählt werden, deren Nutzen den zusätzlichen Aufwand rechtfertigt. Microsoft: Einsatzgrenzen von Event Sourcing.

Wo Microservices ins Bild passen

Microservices teilen eine Anwendung in eigenständige Dienste mit fachlicher Verantwortung auf. Im Servicebeispiel könnten Auftragsbearbeitung und Einsatzplanung solche Bereiche sein. Jeder Dienst verantwortet seine Daten und stellt sie über vereinbarte Schnittstellen bereit. Ziel ist, Dienste unabhängig entwickeln und ausliefern zu können.

Für die Zusammenarbeit kommen direkte API-Aufrufe und Nachrichten infrage. Event Sourcing kann innerhalb eines einzelnen Dienstes verwendet werden; andere Dienste können ihren aktuellen Zustand konventionell speichern. Es lässt sich ebenso in einer zusammenhängenden Anwendung einsetzen.

Mit mehreren Diensten steigen die Anforderungen an Bereitstellung, Tests und Fehlersuche. Zusammenhängende Vorgänge müssen über Dienstgrenzen hinweg nachvollziehbar sein. Kleine Dienste allein ergeben deshalb noch keine einfach zu betreibende Gesamtlösung. Microsoft: Eigenschaften und Herausforderungen von Microservices.

Verwaltete Cloud-Dienste können einen Teil dieser technischen Betriebsaufgaben übernehmen. Wie sich das auf Entwicklungszeit, Kosten und Verantwortung auswirkt, erklärt der Artikel zur cloud-nativen Softwareentwicklung mit AWS.

Für ein überschaubares Vorhaben würde ich zunächst eine Anwendung mit klar getrennten internen Modulen prüfen. Ein solcher modularer Monolith wird gemeinsam ausgeliefert. Einzelne Teile lassen sich später bei entsprechendem Bedarf herauslösen; gute Modulgrenzen erleichtern diesen Weg. Martin Fowler beschreibt die Gründe für einen solchen Einstieg und die Schwierigkeiten einer späteren Aufteilung in Monolith First.

Welche Fehlerfälle zur Planung gehören

Eine Nachricht wird doppelt verarbeitet

Nach einer Unterbrechung kann eine Nachricht erneut zugestellt werden. Die Verarbeitung sollte idempotent sein: Derselbe Vorgang darf dadurch nicht versehentlich zweimal wirken. Im Beispiel darf eine doppelte Terminmeldung keine zweite identische Benachrichtigung auslösen. Dafür müssen Verarbeitung und Erkennung bereits bearbeiteter Nachrichten zusammenpassen. AWS: wiederholte Zustellung beim Outbox-Muster.

Die Änderung ist gespeichert, die Nachricht fehlt

Speichert eine Anwendung zuerst den Termin und versendet danach die Nachricht, kann sie zwischen beiden Schritten ausfallen. Das Transactional-Outbox-Muster speichert Änderung und ausgehende Nachricht gemeinsam in einer Datenbanktransaktion. Ein separater Prozess übernimmt anschließend den Versand. Wiederholungen bleiben dabei einzuplanen. Das Muster hilft auch Anwendungen, die ihren aktuellen Zustand ohne Event Sourcing speichern. AWS: Transactional Outbox.

Verschiedene Anzeigen zeigen unterschiedliche Stände

Bei asynchroner Verarbeitung kann die Disposition schon den neuen Termin kennen, während das Portal noch den alten zeigt. Eventual Consistency bedeutet, dass die beteiligten Datenstände bei erfolgreicher Weiterverarbeitung zusammengeführt werden. Für Nutzer sollte erkennbar sein, wenn eine Aktualisierung noch läuft. Fachlich verbindliche Entscheidungen, etwa die Belegung eines Termins, brauchen eine dafür zuständige Instanz mit passenden Konsistenzregeln. Microsoft: Datenkonsistenz in ereignisgesteuerten Systemen.

Erfahrung aus meinen Projekten

In allen meinen Projekten bei Jungheinrich, VTG und MOIA kamen verteilte Systeme, Microservices und Event Sourcing zum Einsatz. Meine Aufgaben umfassten die Entwicklung von Diensten und Schnittstellen, die Verarbeitung von Daten und die Begleitung des produktiven Betriebs:

• Jungheinrich: Bei der schrittweisen Modernisierung des Flottenmanagements wirkte ich an der Ablösungsstrategie mit und entwickelte Dienste, Schnittstellen und Weboberflächen. Im Projekt zur Auslastung einer Staplerflotte konzipierte und entwickelte ich die Verarbeitung von Fahrzeug- und Nutzungsdaten.
• VTG: Für die Telematikplattform traigo arbeitete ich an Diensten zur Verarbeitung von Telemetrie- und Sensordaten, an Auswertungen und an der Bereitstellung der Daten über Schnittstellen.
• MOIA: Bei den Preis- und Kundenprozessen der Ridesharing-Plattform entwickelte und betreute ich Backend-Dienste und APIs. Dazu gehörte auch ein Dienst für Fahrtenhistorie und Rechnungsdownload. Als Technical Designer wirkte ich an Architekturentscheidungen und der Abstimmung mit anderen Teams mit.

Diese Erfahrung hilft mir, bei einer Architekturentscheidung auch die Schnittstellen, Abhängigkeiten und den späteren Betrieb zu berücksichtigen.

Mit dem fachlichen Bedarf beginnen

Vor einer Architekturentscheidung würde ich diese Fragen klären:

• Welche Teile müssen unabhängig verfügbar sein oder wachsen können?
• Welche Antwort wird sofort gebraucht, und welche Folgearbeit darf warten?
• Welcher Verlauf wird später tatsächlich benötigt?
• Wer entscheidet verbindlich über Aufträge, Termine oder Bestände?
• Wer überwacht Fehler, korrigiert Ausnahmen und betreut die Lösung?

Für Ihren Betrieb beginnt die Entscheidung mit dem Ablauf und seinen Anforderungen. Eine Prozessanalyse kann diese Grundlage schaffen. Darauf aufbauend lassen sich die passenden Schnittstellen und die Software zur Prozessautomatisierung umsetzen. Wenn eigenständige fachliche Dienste benötigt werden, beschreibt mein Angebot zur Microservices-Entwicklung Konzeption, Umsetzung und Betrieb.

Quellen und Einordnung

Die verlinkten Architekturleitfäden von Microsoft und AWS sowie die Fachartikel von Martin Fowler erläutern die technischen Prinzipien und ihre Grenzen. Die Beispiele für Service, Auftragsabwicklung und Betriebsdaten sind eigene Veranschaulichungen; daraus werden keine gemessenen Einsparungen abgeleitet. Der Abschnitt zur Projekterfahrung beschreibt meine Arbeit mit verteilten Systemen, Microservices und Event Sourcing bei Jungheinrich, VTG und MOIA. Quellen ursprünglich geprüft am 13. September 2026. Die ergänzten AWS-Quellen zu SNS/SQS, Standardqueues und Outbox sowie der Microservices-Leitfaden wurden am 7. Oktober 2026 geprüft.