In der heutigen digitalen Welt sind Anwendungen und Systeme zunehmend darauf angewiesen, nicht nur Daten dauerhaft zu speichern, sondern auch laufende Prozesse dauerhaft und unterbrechungsfrei auszuführen. Datenschutz und Prozesskontinuität sind dabei entscheidend, insbesondere bei unternehmenskritischen Anwendungen wie Hotelreservierungssystemen oder umfangreichen Dokumentenindexierungsjobs. Diese Prozesse dürfen bei einem Systemabsturz oder Neustart nicht einfach verloren gehen – hier kommt das Konzept der langlebigen Workflows oder Durable Workflows ins Spiel. Sie ermöglichen es Programmen, den laufenden Verarbeitungsstatus regelmäßig zu sichern und im Fehlerfall genau an dieser Stelle wieder anzusetzen. Doch wie sieht die passende Architektur für solche langlebigen Workflows aus? Welche technischen Herausforderungen und Kompromisse sind mit den unterschiedlichen Ansätzen verbunden? Dieser Beitrag beleuchtet die Architekturoptionen, mit denen Entwickler beim Aufbau langlebiger Workflows konfrontiert sind, und untersucht insbesondere die Gegenüberstellung von extern orchestrierten Systemen und eingebetteten Ausführungslösungen.
Um die Konzepte anschaulich zu machen, greifen wir auf eine Fallstudie zurück, die einen Dokumentenindexierungsprozess als Referenzanwendung nutzt. Dieses Beispiel verdeutlicht die Implementierungsunterschiede, den Umfang des notwendigen Codes sowie die betriebliche Komplexität bei beiden Ansätzen. Zudem zeigen wir auf, worin die wichtigsten Vor- und Nachteile der beiden Vorgehensweisen bestehen und wie Entwickler diese bei der Planung ihrer langlebigen Workflow-Systeme berücksichtigen sollten. Zunächst einmal: Was bedeutet dauerhaftes oder langlebiges Ausführen von Workflows eigentlich? Vereinfacht ausgedrückt, arbeiten langlebige Workflows mit dem Prinzip der periodischen Speicherung des Verarbeitungszustands. Das bedeutet: An definierten Punkten in einem Programm wird der aktuelle Stand auf einer dauerhaften Speichereinheit – zum Beispiel einer Datenbank – zwischengespeichert.
Fällt das System dann aus oder wird neu gestartet, ist es möglich, das Programm nicht erneut von vorne zu starten, sondern genau am zuletzt gesicherten Punkt fortzusetzen. Dies minimiert Datenverluste, vermeidet zeitintensive Neustarts und erhöht die Zuverlässigkeit der Anwendung erheblich. In der Praxis bestehen langlebige Workflows meist aus einer Kette oder einem Graphen von Einzelschritten. Jeder Schritt erhält eine Eingabe, führt bestimmte Operationen aus, und liefert ein Ergebnis zurück. Die Workflow-Engine oder das Ausführungssystem verwaltet den Ablauf von Schritt zu Schritt und sorgt für die Sicherung aller Zwischenergebnisse.
Im Falle eines Ausfalls wird so genau nachvollziehbar, welche Schritte abgeschlossen sind und welche noch ausstehen. Das Ziel ist klar: Ohne explizite manuelle Eingriffe sollen diese Prozesse nahtlos wieder aufgenommen werden können. Bei der Umsetzung langlebiger Workflows gibt es grundsätzlich zwei weitverbreitete Architekturstile: externe Orchestrierungssysteme und eingebettete Ausführungslösungen. Externe Orchestrationsplattformen wie Temporal trennen das Management der Workflows und deren Ausführung vom Kern der Anwendung. Dabei kümmert sich ein spezialisierter Orchestrator (die Workflow-Engine) um die Steuerung, Terminisierung und den Status der Workflows, während sogenannte Worker die tatsächlich durchzuführenden Aufgaben abarbeiten.
Diese Komponenten kommunizieren über Nachrichtenprotokolle und laufen meist auf separaten Servern. Dieses Modell bietet klare Grenzen zwischen Steuerung und Ausführung, kann aber die Anwendungsarchitektur stark fragmentieren, da die Anwendung in unterschiedliche Teildienste gesplittet werden muss. Der Vorteil liegt vor allem in der unabhängigen Skalierbarkeit und Verwaltung der einzelnen Services sowie in der klaren Trennung von Verantwortlichkeiten. Der zweite Ansatz basiert auf eingebetteten langlebigen Ausführungssystemen, etwa der Open-Source-Bibliothek DBOS Transact. Hier wird die Logik zur dauerhaften Ausführung direkt in den Anwendungscode integriert.
Entwickler annotieren wichtige Funktionen als Workflows oder Schritte. Die Bibliothek kümmert sich dann automatisch im Hintergrund um die Speicherung des Workflow-Status, die Wiederaufnahme nach Fehlern und die parallele Ausführung von Arbeitseinheiten. Dieser Ansatz erfordert keine separaten Orchestrierungsdienste oder zusätzlichen Server, da alles innerhalb der Anwendung und der bereits genutzten Datenbank geschieht. Das hält die Architektur simpel und leichtgewichtig, ermöglicht aber nicht die gleiche granulare Steuerung und organisatorische Separation wie externe Orchestratoren. Anhand eines konkreten Beispiels lässt sich die Tragweite dieser Architekturentscheidungen besonders gut verdeutlichen.
Als Referenzanwendung dient eine Pipeline zur Dokumentenindexierung, die auf einem aufgeräumten Microservice-Szenario basiert. Die Anwendung ermöglicht die Verarbeitung großer Mengen an Dokumenten, die anschließend durch ein Retrieval Augmented Generation (RAG)-System abgefragt werden können. Ein typischer Anwendungsfall ist hier die Indexierung von umfangreichen Jahresberichten oder SEC-Filings, um präzise und schnelle Finanzanalysen zu unterstützen. Da jeder Indexierungsvorgang zeitintensiv ist und Dokumente parallel verarbeitet werden, profitiert die Anwendung enorm von langlebigen Workflows, da Abstürze oder Unterbrechungen keinen kompletten Neuauftakt der Verarbeitung erzwingen. Im ursprünglichen Zustand ohne langlebige Ausführung läuft das Indexierungssystem asynchron, jedoch ohne Statusüberwachung oder Wiederaufnahmefähigkeit.
Fällt der Server aus, nachdem beispielsweise vier von zehntausend Dokumenten verarbeitet wurden, weiß niemand unmittelbar, welche Dokumente erfolgreich abgeschlossen wurden und welche nicht, geschweige denn dass der Prozess automatisch fortgesetzt werden könnte. Nutzer müssten manuell nachhaken, Logdateien durchsuchen und verbleibende Dokumente erneut einspeisen. Eine klare, skalierbare Lösung ist das nicht. Beim Einsatz der eingebetteten DBOS Transact Bibliothek zeigt sich eine minimale Integrationshürde. Es müssen im Beispiel lediglich wenige Codezeilen verändert oder hinzugefügt werden, um die Hauptfunktion zur Dokumentenindexierung als Workflow zu deklarieren und den einzelnen Indexierungsvorgang als Schritt zu kennzeichnen.
Zudem ersetzt DBOS eine eigene Warteschlange zur parallelen Verarbeitung der Dokumente, wodurch die parallele Verarbeitung trotz Fehlerfestigkeit gewährleistet bleibt. Das Ergebnis: Sollte das Programm ausfallen, fährt es beim Neustart selbstständig mit genau den noch nicht abgearbeiteten Dokumenten fort. Diese Lösung bringt geringe bis keine Änderungen an der bestehenden Architektur oder am Betriebsaufwand mit sich – ein wesentlicher Vorteil für Entwickler, die schnelle und zuverlässige Lösungen suchen, ohne ihre gesamte App neu strukturieren zu müssen. Anders gestaltet sich dies bei Verwendung des externen Orchestrationssystems Temporal. Die Integration ist deutlich tiefgreifender.
Die bestehende Anwendung wird in verschiedene Komponenten aufgespalten: der API-Server, der die HTTP-Anfragen entgegennimmt, fungiert nun als Temporal-Client und jagt Jobs an den Temporal-Orchestrator. Die eigentliche Indexierungslogik wird in einem separaten Worker-Service ausgeführt, der vom Orchestrator gesteuert wird. Darüber hinaus ist das Aufsetzen und Betreiben eines zusätzlichen Temporal-Servers erforderlich, der als zentraler Koordinator dient und den Zustand der Workflows verwaltet. Durch die Aufteilung des Systems in drei separate Dienste erhöht sich die Komplexität erheblich – nicht nur beim Schreiben des Codes, wo allein mehr als 100 weitere Zeilen eingebracht werden, sondern auch im laufenden Betrieb. Der Bedarf, Verfügbarkeit und Skalierung aller Dienste sicherzustellen, sorgt für zusätzlichen administrativen und technischen Aufwand.
Diese fragmentierte Architektur birgt allerdings auch ihre Vorteile: Sie erlaubt eine feinere Steuerung, robustere Skalierung einzelner Komponenten und klare Verantwortungsbereiche. In manchen Unternehmen mit großen Teams und hochkomplexen Prozessen kann genau das zum Schlüssel für einen stabilen Betrieb werden. Dennoch ist der erhöhte Bedarf an DevOps-Kompetenzen und die Komplexität bei der Fehlersuche und beim Deployment eine reale Herausforderung. Die Wahl zwischen extern orchestrierten und eingebetteten langlebigen Workflows ist letztlich eine Abwägung zwischen Einfachheit und Modularität, zwischen schneller Integration und Skalierbarkeit. Eingebettete Systeme wie DBOS sind besonders attraktiv für Startups und kleine Teams, die ihre bestehenden Anwendungen möglichst wenig umgestalten wollen, aber trotzdem die Ausfallsicherheit und Zuverlässigkeit ihrer Prozesse gewährleisten müssen.
Sie profitieren insbesondere davon, dass keine zusätzlichen Dienste zu betreiben sind, was die Fehlerquellen reduziert und die Betriebskosten senkt. Externe Orchestratoren wie Temporal hingegen kommen eher dort zum Tragen, wo große, heterogene Systeme mit verteilten Teams arbeiten, Workflows sehr komplex sind und eine mandantenfähige Trennung von Zuständigkeiten erforderlich ist. Die Tatsache, dass diese Systeme Workflows als eigenständige Entitäten managen, gestattet eine ausgefeilte Überwachung, Planung und auch Fehlerbehandlung. Nicht zuletzt bemühen sich Anbieter von eingebetteten Systemen, die Grenzen zwischen einfacher Integration und operativer Kontrolle zu verwischen, indem sie neue Werkzeuge und Schnittstellen anbieten, die teilweise bereits Features traditioneller Orchestratoren aufnehmen. So könnten in Zukunft hybride Modelle entstehen, die die Vorteile beider Architekturansätze zusammenführen.
Für Entwickler und Architekten empfiehlt es sich, frühzeitig den tatsächlichen Bedarf an Workflow-Ausfallsicherheit, Skalierbarkeit und Komplexität ihres Systems zu evaluieren und auf dieser Grundlage eine technologische Entscheidung zu treffen. Aspekte wie bestehende Infrastruktur, Teamkompetenzen, Wartungsressourcen und geplante Anwendungserweiterungen sollten in die Entscheidungsfindung mit einfließen. Abschließend zeigt die Gegenüberstellung der beiden herangezogenen Systeme – DBOS als eingebettete Bibliothek und Temporal als extern orchestriertes System – sehr deutlich die architektonischen Trade-offs, die mit langlebigen Workflows verbunden sind. Wo DBOS sich durch wenige Codezeilen und minimale Architekturänderungen auszeichnet, verlangsamt Temporal den Entwicklungsprozess durch umfangreiche Umstrukturierungen und erhöhten Betriebskomplexitätsaufwand. Dennoch hat jedes System seine Daseinsberechtigung im Spektrum verschiedener Anwendungsszenarien.
