Cloudflare Dynamic Workflows: Wann sich die Migration pro Lane lohnt

Was mich überrascht hat

Ich hatte mit einer Ankündigung nach dem Muster „Workflows skaliert jetzt weiter“ gerechnet: höhere Obergrenzen, mehr Kapazität in der Warteschlange, das übliche jährliche Plus. Das war jedoch nur der kleinere Teil.

Entscheidend ist, dass sich Workflow-Code nun zur Laufzeit je Mandant unterscheiden kann. @cloudflare/dynamic-workflows erschien am 1. Mai unter MIT-Lizenz und basiert auf Dynamic Workers. Damit lässt sich ein einzelner WorkflowEntrypoint registrieren, dessen Body beim Erstellen einer Instanz aus einem Dynamic Worker aufgelöst wird. Der Schrittgraph wird also vom jeweiligen Mandanten geprägt, statt fest im Deployment zu stecken. Cloudflare beschreibt das selbst als „durable execution that follows the tenant“ – eine bemerkenswert präzise Formulierung für alle, die schon einmal versucht haben, kundenspezifische Logik mit Feature Flags an einen einzigen Workflow anzubauen.

Meine sechs Publisher-Routinen – News, Dev, Build, Design, Marketing, Founders, Business – sind funktional sechs Mandanten, die sich einen PublishWorkflow teilen. Es sind keine Kunden, sondern KI-Routinen auf Anthropic-Seite, die jeweils eine andere Content-Lane bedienen. Trotzdem passt das Multi-Tenant-Modell exakt: dieselbe Orchestrierungsbasis, je Lane eine leicht andere Ausprägung, alles im selben Cloudflare-Konto ausgeführt.

Wenige Tage später erschien Workflows V2. Dabei ist die Einordnung im zugehörigen Beitrag wichtiger als die Zahlen. V2 wurde ausdrücklich für Workflow-Instanzen neu konzipiert, die Agenten in Maschinengeschwindigkeit erzeugen – nicht Menschen per Mausklick. Genau diesem Trigger-Muster entspricht mein System. Entscheidet eine Publisher-Routine, einen Artikel zu veröffentlichen, erzeugt ein maschineller Auslöser eine dauerhafte Ausführungsinstanz. Die Control Plane von V1 war für eine andere Lastform gebaut.

Was das für nicht technische Gründer bedeutet

„Durable Execution“ klingt wie ein Begriff, der abschrecken soll. Dahinter steckt etwas Einfaches: Ein mehrstufiger Prozess übersteht einen Absturz und setzt beim zuletzt abgeschlossenen Schritt fort, statt wieder von vorn zu beginnen. Fällt Schritt 5 von 8 aus, weil eine API nicht erreichbar war, wiederholt das System Schritt 5 – nicht die Schritte 1 bis 4. Entsprechend werden diese Schritte auch nicht erneut abgerechnet.

Genau darauf kommt es für Gründer an. Die Wiederholungsgrenze jedes Schritts ist zugleich seine Kostengrenze. Ruft eine Pipeline in Schritt 3 ein kostenpflichtiges KI-Modell und in Schritt 6 ein weiteres auf, während Schritt 7 abstürzt, soll nur Schritt 7 wiederholt werden – nicht der gesamte Prozess. Eine nicht idempotente Wiederholung in einer kostenpflichtigen Pipeline erzeugt nicht bloß eine doppelte Datenbankzeile, sondern eine doppelte Rechnung.

Die Entscheidung „bauen oder vertagen?“ lässt sich einem Auftragnehmer in einem Satz mitgeben: Workflows nur dann nach Produktlinie aufteilen, wenn sich die Logik der Linien tatsächlich unterscheidet – nicht bloß, weil die Plattform es jetzt ermöglicht. Cloudflare hat eine leistungsfähige neue Abstraktion veröffentlicht, die schnell zu einem entsprechenden Redesign verleitet. Doch N Workflow-Definitionen bedeuten den N-fachen Wartungsaufwand; der Nutzen entsteht erst, wenn die Lanes wirklich unterschiedliche Arbeit erledigen. Wer den Vorschlag hört, jede Produktlinie nun in einen eigenen Workflow zu zerlegen, sollte daher fragen, was sich an der Arbeit geändert hat – nicht, was die Plattform verändert hat.

Meine tatsächliche Architektur

Der Aufbau ist überschaubar. Jede Publisher-Routine auf Anthropic-Seite schließt ihre Recherche ab, erstellt ein Briefing und sendet es per POST an /api/admin/publish auf der Website. Dieser Endpunkt validiert die Nutzlast, erzeugt eine Instanz-ID und ruft instances.create für einen einzelnen WorkflowEntrypoint namens PublishWorkflow auf.

Der Workflow besteht aus acht idempotenten step.do-Phasen:

1. validate (Briefing-Schema, Eindeutigkeit des Slugs)
2. ground (Quellenabruf, Auflösung der Links)
3. generate (Claude-Aufruf für den Text)
4. clean (Validierung der Markdown-Direktiven)
5. persist (Postgres-Eintrag, Versionierung)
6. index (Embeddings, Aktualisierung der Suche)
7. cover (Bilderzeugung und Upload nach R2)
8. publish (Statuswechsel, Sitemap-Ping)

export class PublishWorkflow extends WorkflowEntrypoint<Env, PublishParams> {
  async run(event: WorkflowEvent<PublishParams>, step: WorkflowStep) {
    const brief = await step.do("validate", () => validateBrief(event.payload));
    const grounded = await step.do("ground", () => groundCitations(brief));
    const draft = await step.do("generate", () => generateBody(grounded));
    const cleaned = await step.do("clean", () => validateDirectives(draft));
    const row = await step.do("persist", () => persistArticle(cleaned));
    await step.do("index", () => reindex(row.id));
    await step.do("cover", () => generateCover(row.id));
    await step.do("publish", () => flipStatus(row.id));
  }
}

Die Dispatch-Grenze sieht so aus:

const id = `publish-${brief.brief_id}`;
try {
  await env.PUBLISH.create({ id, params: brief });
} catch (e) {
  if (isDuplicateIdError(e)) return new Response("already queued", { status: 200 });
  throw e;
}

instances.create löst bei einer doppelten ID einen Fehler aus. Auf dieser einen Zeile lastet ein wesentlicher Teil der Architektur: Nur sie verhindert, dass eine erneut ausgelöste Anthropic-Routine denselben Artikel zweimal veröffentlicht und die darin enthaltenen KI-Aufrufe doppelt berechnet werden.

Warum nur eine Definition für sechs Lanes? Weil alle sechs exakt dieselben acht Phasen durchlaufen. Lediglich das redaktionelle Paket variiert – Tonalitätsvorgaben, Zielgruppendefinition, Liste unerwünschter Muster und Hinweise aus dem Briefing. All das wird zur Laufzeit als Daten im Dispatch-Payload mitgegeben, nicht als Code. Der Name der Lane bestimmt, welches Paket Schritt 3 (generate) erhält; alle anderen Schritte sind unabhängig von der Lane.

Der Knackpunkt – und der einzige ehrliche Grund, Dynamic Workflows überhaupt in Betracht zu ziehen – ist eine Lane, die allmählich einen anderen Schrittgraphen benötigt und nicht bloß ein anderes Paket. Die rechercheintensive Lane braucht vor der Generierung einen zusätzlichen Grounding-Durchlauf und möglicherweise anschließend eine Faktenprüfung. Das ist ein struktureller Unterschied, kein Unterschied bei den Daten. Derzeit steckt diese Abweichung in einer bedingten Verzweigung innerhalb von ground. Das funktioniert, wird aber schnell unübersichtlich, sobald drei weitere Lanes eigene Sonderfälle ergänzen.

Die Migration zu Cloudflare Dynamic Workflows – nüchtern kalkuliert

Genau hier liegt der Nutzen von createDynamicWorkflowEntrypoint. Der Workflow-Code jeder Lane wird zur Laufzeit aus einem Dynamic Worker geladen. Lanes, die an einem Tag nicht aktiv werden, verursachen dadurch nahezu keine laufenden Vorhaltekosten. Statt permanent alle Lanes in einem gemeinsamen Bundle bereitzustellen, kann ihr Code unabhängig weiterentwickelt werden, ohne die gemeinsame Basis neu zu deployen.

Der tatsächliche Preis dafür kommt in der Ankündigung weniger zur Sprache. An die Stelle eines einzigen typgeprüften WorkflowEntrypoint, bei dem der Compiler Abweichungen im Eingabevertrag eines Schritts meldet, treten N zur Laufzeit geladene Definitionen ohne diese Absicherung. Abweichende Schrittverträge zwischen den Lanes werden damit von Build- zu Laufzeitfehlern. Wenn bei sechs Lanes der Schritt persist in zwei Fällen eine leicht abweichende Zeilenstruktur erwartet, weil nur die Hälfte der Lanes refaktoriert wurde, fällt das erst auf, wenn ein echter Artikel veröffentlicht werden soll – nicht schon im CI-Lauf.

Die Migration ist kein Alles-oder-nichts-Projekt. Wer sie so behandelt, baut unnötig komplex. Mein Plan sieht folgendermaßen aus:

1. Die gemeinsame Basis mit 8 Phasen bleibt ein statischer WorkflowEntrypoint. Das ist der Hot Path, den fünf der sechs Lanes unverändert nutzen.
2. Die rechercheintensive Lane entsteht als Dynamic Workflow mit eigenem Schrittgraphen – zusätzlicher Grounding-Durchlauf und Faktenprüfung.
3. Die Auswahl erfolgt je Lane an der Grenze /publish: Ein einzeiliger Switch über brief.lane entscheidet, auf welchem Binding create aufgerufen wird.

Die Entscheidungsregel mit konkreter Schwelle lautet: Eine Lane erhält erst dann einen eigenen Dynamic Workflow, wenn ihr Schrittgraph um mehr als eine Phase von der gemeinsamen Basis abweicht. Unterhalb dieser Schwelle ist eine bedingte Verzweigung im vorhandenen Schritt leichter zu warten als eine zweite Workflow-Definition. Oberhalb davon verschleiert die Verzweigung, was die Lane tatsächlich tut – dann lohnt sich eine eigene Definition.

Eine Lane liegt über dieser Schwelle, fünf darunter. Damit ist der Migrationsplan in zwei Sätzen beschrieben. Legte mir ein Auftragnehmer auf Grundlage desselben Briefings den Vorschlag vor, vom ersten Tag an alle sechs Lanes in Dynamic Workflows aufzuteilen, würde ich das nicht freigeben. Die Umsetzungskosten sind real, während sich der Nutzen auf exakt eine Lane konzentriert.

Was sich mit Cloudflare Workflows V2 bei Triggern in Maschinengeschwindigkeit ändert

Die wichtigsten V2-Zahlen: 50,000 gleichzeitige Instanzen und 2,000,000 Instanzen in der Warteschlange pro Workflow; in V1 waren es 1,000,000 wartende Instanzen. Das sind keine bloßen Prestigezahlen, sie liegen jedoch weit jenseits dessen, was mein System benötigt. Bei sechs Routinen, die jeweils ein- oder zweimal täglich anlaufen, bleibe ich ungefähr neun Größenordnungen unter der neuen Obergrenze.

Für meinen Stack sind nicht die Zahlen entscheidend. Relevant ist, dass die Control Plane von V2 auf agentengesteuerte Instanzerzeugung als Regelfall zugeschnitten wurde. V1 war für von Menschen ausgelöste Abläufe optimiert: Ein Nutzer klickt auf eine Schaltfläche, eine Instanz startet, das System verarbeitet eine stoßweise, aber begrenzte Last. V2 geht von einem Prozess als Auslöser aus, nicht von einer Person. Die Rate richtet sich folglich nach dem Durchsatz vorgeschalteter Agenten und nicht nach Klicks in einer Benutzeroberfläche.

Deterministisches Replay ist die V2-Eigenschaft, die eine verständliche Erklärung verdient. Jeder Schritt ist isoliert, wiederholbar und idempotent; bei einem erneuten Versuch setzt der Workflow am letzten erfolgreichen Schritt fort. Genau diese Eigenschaft sichere ich an der Dispatch-Grenze bereits manuell mit der Instanz-ID publish-{brief_id} ab. V1 bot bereits die Wiederholungsgarantie pro Schritt. V2 festigt die Replay-Semantik, sodass die von mir geschützte strukturelle Eigenschaft nun zusätzlich von der darunterliegenden Plattform durchgesetzt wird.

Die praktische Maßnahme für diese Woche: keine Änderung am Hot Path. Das V2-Modell ist Opt-in und wird per erneutem Deployment aktiviert. Eine funktionierende idempotente Pipeline sollte nicht überstürzt auf eine neue Control Plane verschoben werden – schon gar nicht wegen einer Semantik, die sie bereits besitzt. Die rechercheintensive Lane wechselt zu V2, wenn ich sie als Dynamic Workflow baue, denn neuer Code lässt sich günstig auf dem neuen Modell aufsetzen. Die fünf statischen Lanes bleiben unverändert, bis es einen anderen Anlass gibt als „die Plattform hat eine neue Version veröffentlicht“.

Idempotente Workflows: die eine Invariante, die nicht zur Disposition steht

Die Instanz-ID publish-{brief_id} ist ein tragendes Bauteil. Ohne diesen Schlüssel wird die Pipeline erneut ausgelöst, sobald eine Anthropic-Routine auf ihrer Seite einen weiteren Versuch startet. Der gleiche Artikel erscheint zweimal und jeder kostenpflichtige API-Aufruf im Workflow-Body wird doppelt berechnet.

Dynamic Workflows gefährdet diese Invariante nicht unmittelbar. Der ID-Vertrag von instances.create bleibt unverändert. Gefährlich wäre vielmehr ein nachlässiges Refactoring pro Lane, bei dem der jeweilige Code die ID lokal neu ableitet – etwa wenn eine Lane vermeintlich sicherheitshalber einen Zeitstempel in die ID aufnimmt. Dadurch fällt die Deduplizierung unbemerkt aus, weil jeder Wiederholungsversuch eine neue ID erzeugt.

Die Regel, die jedes Versionsupgrade übersteht und vor jeder Änderung am Code unübersehbar festgehalten werden sollte:

Eine solche Invariante findet sich weder in einer Produktankündigung noch in einer Migrationsanleitung. Sie entsteht erst, wenn der Fehler, den sie verhindert, schon einmal in der Praxis aufgetreten ist. Die Kostenbegrenzung – damit ein einzelner Workflow-Lauf selbst bei versagender Deduplizierung keine ausufernde Rechnung verursacht – bildet eine separate Schicht auf Ebene der Modellaufrufe statt der Instanzen. Beide Schichten haben denselben Zweck: In einer Pipeline, in der jeder Schritt Geld kostet, ist strukturelle Korrektheit die günstigste Versicherung überhaupt.

Was ich bei einem Neustart im Mai 2026 anders machen würde

Würde ich diesen Stack heute neu aufbauen, statt Entscheidungen aus dem Vorjahr zu übernehmen, würde ich drei Dinge ändern.

Erstens würde ich mit einer gemeinsamen statischen Basis und einem Dynamic Workflow für eine tatsächlich abweichende Lane beginnen – nicht mit sechs separaten Definitionen. Eine neue Abstraktion überall einzusetzen, ist verlockend, doch der Wartungsaufwand für N Workflow-Definitionen entsteht früher als ihr Skalierungsvorteil. Sechs Definitionen bedeuten sechs Stellen für eine Fehlerkorrektur, sechs Stellen für das Upgrade einer Abhängigkeit und sechs Stellen, an denen ein Schrittvertrag auseinanderlaufen kann. Eine gemeinsame Basis plus ein Ausreißer ist die kleinstmögliche sinnvolle Trennung.

Zweitens würde ich den Idempotenzschlüssel vom ersten Tag an der HTTP-Grenze platzieren. publish-{brief_id} erst nach einem Vorfall mit doppelter Veröffentlichung nachzurüsten, ist die teure Variante: Die doppelten Datenbankzeilen müssen bereinigt, die entstandenen Mehrkosten erstattet und die Dispatch-Schicht im laufenden Produktivbetrieb instrumentiert werden. Das Muster try { create({id}) } catch (dup) {} vor der ersten Veröffentlichung einer Pipeline einzubauen, kostet zehn Minuten und verhindert eine ganze Fehlerklasse.

Drittens würde ich den Determinismus von Workflows V2 als Grundlage des Designs behandeln, nicht als Feature für einen späteren Opt-in. Jeder Schritt sollte Replay-sicher entworfen sein, selbst wenn die Obergrenze von 50k parallelen Instanzen nie erreicht wird. Replay-Sicherheit ist keine Skalierungs-, sondern eine Korrektheitseigenschaft. Ein Schritt, der sich nicht sicher wiederholen lässt, scheitert bei einem Retry – und Retries gibt es in jeder Größenordnung.

Darin zeigt sich erfahrenes Engineering, auch wenn es wie eine rein technische Entscheidung aussieht. Die Falle besteht darin, neue Plattformfunktionen als Features zu behandeln, die man übernehmen sollte. Disziplin heißt, sie als Randbedingungen für das Design zu verstehen – unabhängig davon, ob der zusätzliche Spielraum jemals gebraucht wird.