Temporal: Durable Execution für mission-critical Workflows in Java, Go, TS, Python

Was ist Temporal?

Temporal ist eine MIT-lizenzierte Workflow-as-Code-Plattform, 2019 in Seattle als Spin-off von Uber gegründet (Maxim Fateev, Samar Abbas – die Schöpfer von Uber Cadence). Die Position im Markt ist eindeutig: Temporal liefert „Durable Execution" – Workflows, die garantiert zu Ende laufen, auch wenn Server abstuerzen, Netzwerke ausfallen oder Prozesse neu gestartet werden. State und Code werden vom Temporal-Server persistiert, der Worker spielt den Workflow nach einem Crash exakt an der Stelle weiter, wo er aufgehört hat.

Das Konzept ist anders als Zapier, Make oder n8n. Temporal ist kein Drag-and-Drop-Tool, sondern ein Backend-Framework mit SDKs in Java, Go, TypeScript, Python, .NET, Ruby und PHP. Entwickler schreiben Workflows als reguläre Funktionen in ihrer Sprache, Temporal kuemmert sich um Retry, Timeouts, State-Management, Versioning und Multi-Datacenter-Replication. Stand Mai 2026 sind Workflow-Versionen 1.x und Temporal Server 1.27+ produktiv.

Kommerziell gibt es zwei Pfade: Self-Hosted unter MIT-Lizenz (frei, Docker-Compose oder Kubernetes-Setup auf eigener Infrastruktur) und Temporal Cloud (Managed-Service, ab USD 100/Monat für kleinste Tarife, Skalierung nach Actions). Self-Host ist die übliche Wahl für mid-market-Unternehmen – die Cloud lohnt erst ab sehr hohen Volumina oder für Teams, die kein Ops-Knowhow für Temporal-Server haben.

Die Architektur besteht aus dem Temporal Server (mehrere Microservices: Frontend, History, Matching, Worker) plus einer Datenbank-Schicht (Postgres, MySQL oder Cassandra). Die Workers laufen als eigene Prozesse, üblicherweise in den Geschäftsanwendungen selbst – Temporal selbst führt keinen Geschäftscode aus, sondern orchestriert ihn.

Für eine CH-Treuhand ist Temporal eher selten direkt einsetzbar – die Lernkurve und das Setup sind überzogen für 5-15 produktive Workflows. Sinnvoll wird Temporal dort, wo lange Laufzeiten (Stunden, Tage, Wochen) mit komplexem State und garantiertem Retry essentiell sind: Mandanten-Onboarding mit mehrstufigen externen Prüfungen, Abrechnungs-Reconciliation, Multi-Step-Provisioning von Cloud-Ressourcen.

Warum es wichtig ist

Temporal löst ein Problem, das andere Workflow-Tools nicht lösen können: durable execution mit garantierter Korrektheit. Ein typisches Beispiel: ein Bestell-Workflow umfasst Bezahlung (Stripe-Charge), Versand (Logistik-API), Bestätigungs-Mail und Inventar-Aktualisierung. Fällt der Server nach der Bezahlung, aber vor der Versand-Buchung aus, muss der Workflow zuverlässig fortgesetzt werden – ohne doppelte Bezahlung, ohne fehlenden Versand.

In Zapier, Make oder n8n läuft so ein Workflow synchron in einer Engine; ein Crash mittendrin bedeutet undefinierten Zustand. Wer Wiederholungs-Logik bauen will, muss Idempotenz-Keys in jedem externen System verwalten und manuelle Reconciliation-Tools betreiben. In Temporal speichert der Server jeden Workflow-Schritt mit Input und Output; nach einem Crash wird der Workflow exakt an der nächsten unausgeführten Aktivität fortgesetzt.

Für KMU und Treuhand sind die Anwendungsfälle eingeschränkter als bei n8n. Drei realistische Hebel: Erstens – komplexe Mandanten-Onboarding-Prozesse mit GwG-Prüfung. Ein Onboarding-Workflow kann Tage dauern (UID-Verifikation, externe Datenbank-Abfragen, Bonitäts-Prüfung, manuelle Genehmigung). Mit Temporal bleibt der Workflow-Zustand persistent, jeder Schritt ist retry-fähig, und die Approval-Logik ist Teil des Codes.

Zweitens – Abrechnungs-Reconciliation. Stripe-Charges, Rechnungen aus Bexio, Bank-Transaktionen über finstro oder klarx – eine tägliche Reconciliation, die fehlende oder doppelte Buchungen identifiziert, mit manueller Korrektur-Loop. Temporal eignet sich, weil jeder Reconciliation-Run idempotent ist und State (welche Belege bereits verarbeitet) sauber persistiert wird.

Drittens – Multi-Step-Cloud-Provisioning. Wenn eine Treuhand für einen neuen Mandanten ein eigenes ERP-Setup baut (Bexio-Instanz, Cloud-Storage, SSO-Konfiguration, Backup-Job, Mandanten-Schulung), ist das ein Workflow mit Dutzenden Schritten, externen API-Calls und Wiederholungs-Logik. Temporal ist dort eine valide Wahl – n8n wäre eine Alternative, aber bei vielen externen Systemen mit unklaren Failure-Modi gewinnt Temporal an Robustheit.

Die Kehrseite ist klar: Lernkurve, Setup-Aufwand, Ops-Knowhow. Wer Temporal produktiv betreibt, hat ein Engineering-Team mit Erfahrung. Für kleine Treuhand-Setups ist die Investition selten gerechtfertigt.

Wie es funktioniert

Ein Temporal-System besteht aus drei Hauptkomponenten: Temporal Server (Orchestrator), Workers (führen Workflow- und Activity-Code aus) und Clients (starten Workflows). Die Trennung ist fundamental: der Server speichert Workflow-State und entscheidet, welche Activity als nächstes auszuführen ist; die Workers ziehen Aufgaben aus Task-Queues und führen den eigentlichen Geschäftscode aus.

Ein Workflow ist eine Funktion in der Anwendungssprache (Python, Go, Java, TypeScript). Die Funktion enthält die Geschäftslogik – sie ruft Activities auf, wartet auf Signale, behandelt Errors. Wichtig: ein Workflow muss deterministisch sein. Direct API-Calls oder I/O sind in Workflow-Code verboten; alles externe muss in Activities verlagert werden. Activities sind die nicht-deterministischen Funktionen – sie machen HTTP-Calls, DB-Queries, Datei-Operationen.

Das Magic ist die Replay-Funktion. Wenn der Worker abstuerzt, startet Temporal einen anderen Worker und „spielt" die Workflow-Funktion neu durch – aber statt die Activities tatsächlich auszuführen, liefert der Server die gespeicherten Ergebnisse aus dem Workflow-History. So erreicht der Workflow den exakt selben Zustand wie vor dem Crash. Ab der nächsten unausgeführten Activity wird die echte Ausführung wieder aufgenommen.

Ein typisches Beispiel in TypeScript: ein Workflow „onboardClient" wird mit Mandanten-Daten gestartet. Step 1 ruft activity „verifyUID" (gegen ZEFIX-API). Step 2 ruft activity „checkAML" (gegen Compliance-Provider). Step 3 wartet auf ein externes Signal (manuelle Genehmigung). Step 4 ruft activity „createBexioCompany". Schritte 1-2 dauern Sekunden, Schritt 3 kann Stunden bis Tage dauern (manuelle Genehmigung), Schritt 4 wiederum Sekunden. Der gesamte Workflow ist durable – auch wenn der Worker zwischen Step 3 und Step 4 abstuerzt, wird er nach dem Restart exakt mit Step 4 fortgesetzt.

Die SDK-Sprachen unterscheiden sich in Reife: Go und Java sind die aeltesten, TypeScript und Python sind seit 2022 stabil, .NET und Ruby kamen 2023 hinzu, PHP 2024. Funktional sind alle SDKs äquivalent; die Wahl hängt am Tech-Stack der Anwendung.

Temporal hat keine Konnektoren wie Zapier oder n8n. Jede Integration läuft als Activity, die das passende SDK des Drittsystems aufruft (Stripe-SDK, HubSpot-SDK, AWS-SDK). Das ist mehr Boilerplate als bei Visual-Tools, aber dafür voll typisiert und versionierbar.

Temporal Self-Hosted in 5 Schritten

1. 01Docker-Compose-Stack vorbereiten: Temporal-Server (Frontend, History, Matching, Worker), Postgres als DB, Temporal-Web als UI, Caddy/Nginx als Reverse-Proxy.
2. 02SDK für die Anwendungssprache installieren (TypeScript, Python, Go oder Java) und einen ersten Worker-Prozess in der bestehenden Anwendung integrieren.
3. 03Ersten Workflow schreiben: Funktion in TypeScript/Python definieren, Activities als separate Funktionen, Workflow-Test mit Replay-Helper.
4. 04Task-Queues definieren: pro Worker-Typ eine Queue, Workflows registrieren, Worker mit der Queue verbinden. Skalierung erfolgt über mehrere Worker.
5. 05Monitoring einrichten: Temporal-Web für Workflow-History und Debugging, Prometheus-Scraper auf den Server-Metriken, Alert bei Workflow-Failure-Rate > 1%.

Wann Temporal einsetzen

Temporal ist die richtige Wahl, wenn (a) der Workflow mission-critical ist (Geld, Compliance, Kunden-Erlebnis), (b) die Laufzeit von Stunden bis Wochen reichen kann, (c) der State komplex ist (mehrere Zwischenergebnisse, externe Genehmigungen) und (d) das Team Engineering-Knowhow hat.

Konkrete Fälle: Order-Processing in E-Commerce (Payment + Versand + Inventory + Mail), Payment-Reconciliation in Fintech, Multi-Step-Onboarding für regulierte Kunden (KYC, AML, Compliance-Checks), Cloud-Resource-Provisioning (Multi-Step-Setup mit Rollback-Logik), Data-Pipelines mit langer Laufzeit und vielen Failure-Modi.

Für eine CH-Treuhand mit 5-15 Mitarbeitenden ist Temporal selten direkt sinnvoll. Sinnvoll wird es bei einer Treuhand-Plattform mit hunderten Mandanten und automatisiertem Onboarding, oder bei einer SaaS-Lösung, die Temporal als Workflow-Backbone nutzt. Für Standard-Mandanten-Triage, Rechnungs-Sortierung und MWST-Sammeln ist n8n der pragmatischere Weg.

Für Engineering-Teams in grösseren KMU (50+ Mitarbeiter) mit kritischen Workflows ist Temporal eine Investition in Zukunfts-Sicherheit. Die Lernkurve beträgt 1-3 Monate, dafür skaliert die Plattform in den Bereich Millionen Workflows/Tag – kein anderes Tool in der Liste schafft das.

Wann NICHT

Temporal ist die falsche Wahl für einfache SaaS-Verknüpfungen. Wer „Slack-Nachricht bei neuem Stripe-Charge" baut, hat in Zapier 5 Minuten Setup, in Temporal mindestens einen Tag Engineering-Aufwand (Worker-Setup, Activity-Implementation, Workflow-Definition). Für typische KMU-Workflows ist die Komplexität überzogen.

Ungeeignet ist Temporal für No-Code-Teams. Es gibt keine UI für Workflow-Design – alle Workflows werden in Code geschrieben. Marketing- oder Sales-Teams ohne Engineering-Begleitung können Temporal nicht selbst betreiben.

Nicht passend ist Temporal für kleine Self-Host-Setups. Die Server-Komponenten (Frontend, History, Matching, Worker) plus eine Datenbank brauchen mindestens 4 vCPUs und 8 GB RAM, plus Monitoring und Operations-Knowhow. Für 5-15 produktive Workflows ist das überdimensioniert.

Für einfache Daten-Pipelines ist Temporal überdimensioniert. Airflow oder dbt sind effizienter – Temporal ist auf Workflows mit komplexem State und langen Laufzeiten optimiert, nicht auf reine ELT-Batches.

Für KI-Klassifikations-Workflows ohne komplexen State (eingehende Mail klassifizieren, ins CRM eintragen, Slack-Notification) ist Temporal ein Sledgehammer für ein Reissnagel-Problem. n8n, Make oder Activepieces sind die richtige Wahl.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Temporal documentation – concepts and SDKs · 2026-05
2. Temporal Cloud pricing page · 2026-05
3. Temporal on GitHub – MIT-licensed server · 2026-05
4. Temporal durable execution and replay semantics · 2026-04