Core-Engine-Architektur

Aus Erfahrung gewachsen

Diese Architektur ist keine akademische Übung. Sie ist das Ergebnis jahrelanger Arbeit an geschäftskritischen Automatisierungs-Systemen. Wir haben jeden denkbaren Failure-Mode gesehen: API-Rate-Limits, Datenbank-Timeouts, Worker-Crashes, Memory-Leaks.

Deshalb bauen wir auf bewährter Open-Source-Technologie auf – statt eigene Black-Boxes zu erfinden.

• Runtime: Node.js & Nitro für hochperformante asynchrone I/O.
• Datenbank: PostgreSQL für verlässliche, ACID-konforme State-Speicherung.
• Engine: Durable-Execution-Engine für resumable Workflows.

Mit diesen kampferprobten Komponenten fokussieren wir unsere Innovation auf das, was zählt: die Workflow-Abstraktion selbst – nicht das Plumbing.

Durable Execution

dataflows ist auf dem Konzept der Durable Execution aufgebaut. Statt Queues, Wiederholungen und State manuell zu verwalten, schreibst du Standard-TypeScript-Code – die Engine macht ihn automatisch durable.

Reliability-as-Code

Weg von handgerollten Queues und Custom-Retries – hin zu durablem, resumable Code.

• Keine Queues: Du definierst keine Queues oder Worker. Du deklarierst einen Workflow und löst ihn aus.
• Keine Timeouts: Workflows können Sekunden, Tage oder Monate laufen.
• Resumable: Stürzt der Prozess ab, läuft er genau dort weiter, wo er aufgehört hat.

Workflows und Steps

Ein Workflow wird mit defineWorkflow definiert. Innerhalb seiner run-Funktion ist jeder in step.run(...) gewrappte Aufruf ein atomarer, memoisierter Schritt. Die Engine persistiert das Ergebnis jedes Schritts in PostgreSQL – stürzt der Prozess ab und startet neu, werden bereits ausgeführte Schritte übersprungen und aus dem Cache repliziert.

export const copyToClickUp = defineWorkflow({
  id: 'copy-to-clickup',
  trigger: azure.onWorkItemCreated(),

  async run({ event, step }) {
    // Jeder Schritt läuft einmal. Beim Replay wird das Ergebnis
    // aus der DB geholt, statt die API erneut zu treffen.
    const item = await step.run('fetch-item', () =>
      azure.getWorkItem({ id: event.payload.id })
    )

    const task = await step.run('create-task', () =>
      clickup.createTask(item)
    )

    return task
  }
})

Workflows können auch pausieren und auf externe Signale oder Zeit warten:

// Auf eine menschliche Freigabe warten und dann weitermachen – auch Tage später
const decision = await step.waitForEvent('approval', {
  timeout: '7d'
})

await step.sleep('cooldown', '24h')

Execution-Flow

Die Engine verwaltet den Execution-State in PostgreSQL. Schläft ein Workflow oder wartet er auf ein Event, gibt er seinen State ab und gibt Compute-Ressourcen frei.

sequenceDiagram
    participant Webhook
    participant API
    participant Engine
    participant DB

    Webhook->>API: POST /hooks/shopify
    API->>Engine: Workflow starten
    API-->>Webhook: 202 Accepted

    Engine->>DB: Execution anlegen
    Engine->>Engine: Step 1 ausführen
    Engine->>DB: Ergebnis 1 speichern
    Engine->>Engine: Step 2 ausführen
    Engine->>DB: Ergebnis 2 speichern

    Engine->>DB: Suspendieren (Sleep/Wait)
    Note right of Engine: Ressourcen freigegeben

    Engine->>DB: Resume (Timer/Event)
    Engine->>Engine: Steps replayen (gecached)
    Engine->>Engine: Step 3 ausführen