Temporal mit Claude Code: Resiliente Workflows 2026

Distributed Systems scheitern. Netzwerke brechen ab, Datenbanken überlasten, externe APIs antworten nicht. Klassische Worker-Queues (Bull, Celery, Sidekiq) verlieren bei Crashes ihren gesamten In-Memory-State — jeder laufende Job wird zum Datenverlust-Kandidaten.

Temporal löst dieses Problem fundamental anders: Jeder Workflow-State wird nach jeder ausgeführten Aktion persistent in einem Event-Log gespeichert. Crasht ein Worker, startet ein anderer Worker exakt an der Stelle weiter wo der vorige aufgehört hat — ohne dass der Entwickler einen einzigen Zeile Recovery-Code schreiben muss.

Mit Claude Code lassen sich Temporal-Workflows in Minuten implementieren: Claude generiert die komplette TypeScript-Boilerplate, konfiguriert Retry-Policies und erklärt automatisch wo Activities von Workflows getrennt werden müssen. Dieser Artikel zeigt alle zentralen Konzepte mit echtem TypeScript-Code.

1. Temporal Grundlagen — Warum Temporal?

Temporal ist eine Open-Source-Workflow-Engine, die aus dem internen Cadence-Projekt bei Uber entstanden ist. Das Kernprinzip: Durable Execution — Code läuft so, als würde die Ausführung niemals unterbrochen, auch wenn die zugrundeliegende Infrastruktur ausfällt.

🔁

Automatisches Retry

Activities retried automatisch mit konfigurierbarem Backoff — kein try/catch-Spaghetti.

💾

Durable State

Workflow-State überlebt Crashes, Deploys und Restarts vollständig.

⏱

Lange Workflows

Workflows können Tage, Wochen oder Monate laufen — sleep(30 Tage) ist kein Problem.

🔍

Vollständiges Audit-Log

Jede Aktion, jedes Signal, jeder Timer ist persistent nachvollziehbar.

🌐

Polyglot

SDKs für TypeScript, Python, Go, Java — Workflows und Workers können in verschiedenen Sprachen sein.

📊

Web UI

Temporal UI zeigt alle laufenden und vergangenen Workflows mit vollständigem Event-History.

Workflow vs. Activity — Die wichtigste Unterscheidung

Aspekt	Workflow	Activity
Zweck	Orchestrierung / Koordination	Tatsächliche Arbeit / Seiteneffekte
Determinismus	MUSS deterministisch sein	Darf beliebig sein
I/O	KEIN direktes I/O erlaubt	HTTP, DB, Filesystem — alles OK
Retry	Kein Retry (State bleibt)	Automatisches Retry mit Policy
Laufzeit	Sekunden bis Jahre	Sekunden bis Stunden
Sleep	workflow.sleep() — dauerhaft	Normales async/await

Golden Rule: Niemals direktes I/O (fetch, fs, Math.random(), Date.now()) in einem Workflow. Alles was nicht-deterministisch ist, gehört in eine Activity. Claude Code kennt diese Regel und weist automatisch darauf hin.

Lokaler Dev-Server

terminal

# Temporal Dev-Server starten (kein Docker nötig)
npx @temporalio/create-app my-temporal-app
# oder manuell installieren:
npm install @temporalio/workflow @temporalio/activity @temporalio/worker @temporalio/client

# Dev-Server starten
npx temporal server start-dev

# Web UI öffnen
open http://localhost:8233

2. Workflow Definition mit TypeScript

Temporal Workflows werden in TypeScript mit dem @temporalio/workflow-Package definiert. Der entscheidende Punkt: Workflows laufen in einem isolierten, deterministischen V8-Sandbox-Environment. Claude Code erzeugt die korrekte Trennung zwischen Workflow-Code und Activity-Aufrufen automatisch.

WORKFLOW

Workflows orchestrieren den Ablauf. Sie rufen Activities auf (nie direkt I/O), schlafen, warten auf Signals und geben ein Ergebnis zurück.

src/workflows/orderWorkflow.ts

import {
  proxyActivities,
  sleep,
  defineSignal,
  defineQuery,
  setHandler,
  condition,
  ActivityFailure,
  log,
} from '@temporalio/workflow';
import type { OrderActivities } from '../activities/orderActivities';
import type { Order, OrderResult, PaymentStatus } from '../types';

// Activities via Proxy aufrufen — NIEMALS direkt importieren
const {
  validateOrder,
  chargePayment,
  reserveInventory,
  sendConfirmationEmail,
  createShipment,
  updateOrderStatus,
} = proxyActivities<OrderActivities>({
  startToCloseTimeout: '30 seconds',
  retry: {
    maximumAttempts: 3,
    initialInterval: '1 second',
    backoffCoefficient: 2,
    maximumInterval: '30 seconds',
    nonRetryableErrorTypes: ['InvalidOrderError', 'PaymentDeclinedError'],
  },
});

// Signals definieren — externe Events die in den Workflow gesendet werden
export const cancelOrderSignal = defineSignal<[string]>('cancelOrder');
export const paymentReceivedSignal = defineSignal<[PaymentStatus]>('paymentReceived');

// Queries definieren — synchron abfragbarer Workflow-Zustand
export const orderStatusQuery = defineQuery<string>('orderStatus');

// Hauptworkflow-Funktion
export async function orderWorkflow(order: Order): Promise<OrderResult> {
  let currentStatus = 'PENDING';
  let cancelled = false;
  let paymentReceived = false;
  let paymentStatus: PaymentStatus | null = null;

  // Signal-Handler registrieren
  setHandler(cancelOrderSignal, (reason: string) => {
    log.info('Cancel signal received', { reason, orderId: order.id });
    cancelled = true;
    currentStatus = 'CANCELLING';
  });

  setHandler(paymentReceivedSignal, (status: PaymentStatus) => {
    paymentStatus = status;
    paymentReceived = status.success;
  });

  // Query-Handler registrieren
  setHandler(orderStatusQuery, () => currentStatus);

  // Schritt 1: Order validieren
  currentStatus = 'VALIDATING';
  const validationResult = await validateOrder(order);
  if (!validationResult.valid) {
    throw new Error(`Order invalid: ${validationResult.reason}`);
  }

  // Cancellation-Check nach jedem wichtigen Schritt
  if (cancelled) {
    return { orderId: order.id, status: 'CANCELLED', reason: 'Cancelled before payment' };
  }

  // Schritt 2: Auf Payment warten (max 30 Minuten)
  currentStatus = 'AWAITING_PAYMENT';
  const paymentOk = await condition(
    () => paymentReceived || cancelled,
    '30 minutes'
  );

  if (cancelled) {
    return { orderId: order.id, status: 'CANCELLED', reason: 'Cancelled during payment' };
  }
  if (!paymentOk) {
    await updateOrderStatus(order.id, 'PAYMENT_TIMEOUT');
    return { orderId: order.id, status: 'PAYMENT_TIMEOUT', reason: 'Payment timeout after 30 minutes' };
  }

  // Schritt 3: Payment abbuchen
  currentStatus = 'CHARGING';
  await chargePayment(order.id, order.totalAmount, paymentStatus!.paymentMethodId);

  // Schritt 4: Lager reservieren
  currentStatus = 'RESERVING_INVENTORY';
  await reserveInventory(order.id, order.items);

  // Schritt 5: Bestätigungs-Email senden
  currentStatus = 'SENDING_CONFIRMATION';
  await sendConfirmationEmail(order.id, order.customerEmail);

  // Schritt 6: Sendung erstellen
  currentStatus = 'CREATING_SHIPMENT';
  const shipmentId = await createShipment(order.id, order.shippingAddress);

  // 2 Tage warten, dann Status-Update (workflow.sleep = dauerhafter Timer)
  currentStatus = 'SHIPPED';
  await sleep('2 days');
  await updateOrderStatus(order.id, 'DELIVERED');

  currentStatus = 'DELIVERED';
  return { orderId: order.id, status: 'DELIVERED', shipmentId };
}

Beachte: sleep('2 days') ist ein echter dauerhafter Timer — der Worker-Prozess kann währenddessen beliebig oft neu gestartet werden. Temporal weckt den Workflow nach exakt 48 Stunden wieder auf.

3. Activities — Echte Seiteneffekte

Activities sind normale async-Funktionen die beliebige Seiteneffekte ausführen dürfen: HTTP-Requests, Datenbankoperationen, Dateisystem-Zugriffe, externe API-Calls. Das Temporal-Runtime kümmert sich automatisch um Retry bei transientem Fehler.

ACTIVITY

Activities sind zustandslos und retryable. Bei langen Activities muss heartbeat() regelmäßig aufgerufen werden — sonst erkennt Temporal einen Crash nicht rechtzeitig.

src/activities/orderActivities.ts

import { Context } from '@temporalio/activity';
import { db } from '../db';
import { emailClient } from '../email';
import { paymentGateway } from '../payment';
import { shippingApi } from '../shipping';
import type { Order, OrderItem, ValidationResult, ShippingAddress } from '../types';

// Activity-Interface — wird vom Workflow über proxyActivities genutzt
export interface OrderActivities {
  validateOrder(order: Order): Promise<ValidationResult>;
  chargePayment(orderId: string, amount: number, paymentMethodId: string): Promise<void>;
  reserveInventory(orderId: string, items: OrderItem[]): Promise<void>;
  sendConfirmationEmail(orderId: string, email: string): Promise<void>;
  createShipment(orderId: string, address: ShippingAddress): Promise<string>;
  updateOrderStatus(orderId: string, status: string): Promise<void>;
}

// Implementierung — alle Funktionen dürfen echtes I/O nutzen
export async function validateOrder(order: Order): Promise<ValidationResult> {
  // Datenbank-Check: Kundenkonto aktiv?
  const customer = await db.customers.findUnique({ where: { id: order.customerId } });
  if (!customer?.active) {
    return { valid: false, reason: 'Customer account inactive' };
  }
  // Lager-Check: alle Items verfügbar?
  for (const item of order.items) {
    const stock = await db.inventory.findUnique({ where: { sku: item.sku } });
    if (!stock || stock.quantity < item.quantity) {
      return { valid: false, reason: `Insufficient stock for SKU ${item.sku}` };
    }
  }
  return { valid: true };
}

export async function chargePayment(
  orderId: string,
  amount: number,
  paymentMethodId: string
): Promise<void> {
  const result = await paymentGateway.charge({
    amount,
    paymentMethodId,
    metadata: { orderId },
    idempotencyKey: orderId, // Wichtig: Idempotenz bei Retries!
  });
  if (!result.success) {
    // PaymentDeclinedError ist nonRetryable (konfiguriert im Workflow)
    throw Object.assign(new Error(result.message), { name: 'PaymentDeclinedError' });
  }
  await db.payments.create({ data: { orderId, amount, status: 'CHARGED', stripeId: result.id } });
}

export async function reserveInventory(
  orderId: string,
  items: OrderItem[]
): Promise<void> {
  // Heartbeat für lange Operationen — Temporal merkt wenn Worker crasht
  Context.current().heartbeat('Starting inventory reservation');

  await db.$transaction(async (tx) => {
    for (const item of items) {
      Context.current().heartbeat(`Reserving SKU: ${item.sku}`);
      await tx.inventory.update({
        where: { sku: item.sku },
        data: { quantity: { decrement: item.quantity } },
      });
      await tx.reservations.create({
        data: { orderId, sku: item.sku, quantity: item.quantity },
      });
    }
  });

  Context.current().heartbeat('Inventory reservation complete');
}

export async function sendConfirmationEmail(
  orderId: string,
  email: string
): Promise<void> {
  const order = await db.orders.findUnique({ where: { id: orderId }, include: { items: true } });
  await emailClient.send({
    to: email,
    template: 'order-confirmation',
    data: { order },
  });
}

export async function createShipment(
  orderId: string,
  address: ShippingAddress
): Promise<string> {
  const response = await shippingApi.createLabel({
    orderId,
    address,
    service: 'STANDARD',
  });
  await db.shipments.create({
    data: { orderId, trackingNumber: response.trackingNumber, carrier: response.carrier },
  });
  return response.shipmentId;
}

export async function updateOrderStatus(orderId: string, status: string): Promise<void> {
  await db.orders.update({ where: { id: orderId }, data: { status } });
}

Idempotenz ist Pflicht: Activities werden bei transientem Fehler automatisch wiederholt. Operationen wie Zahlungsabbuchung müssen daher idempotent sein — z.B. über einen idempotencyKey oder eine Upsert-Logik in der Datenbank.

4. Signals & Queries — Externe Kommunikation

Temporal ermöglicht bidirektionale Kommunikation mit laufenden Workflows. Signals senden Events an einen Workflow (der Workflow muss auf sie reagieren können), Queries lesen synchron den aktuellen Workflow-Zustand aus — ohne den Workflow zu verändern.

SIGNAL

Asynchron. Ändert den Workflow-Zustand. Kann nicht abgelehnt werden (fire & forget). Beispiel: "Zahlung eingegangen", "Bestellung stornieren".

QUERY

Synchron. Liest nur Zustand, ändert nichts. Sofortige Antwort. Beispiel: "Was ist der aktuelle Status?", "Wie viele Items wurden verarbeitet?".

src/client/workflowClient.ts

import { Client, Connection } from '@temporalio/client';
import {
  orderWorkflow,
  cancelOrderSignal,
  paymentReceivedSignal,
  orderStatusQuery,
} from '../workflows/orderWorkflow';
import type { Order, PaymentStatus } from '../types';

async function getClient(): Promise<Client> {
  const connection = await Connection.connect({
    address: process.env.TEMPORAL_ADDRESS ?? 'localhost:7233',
  });
  return new Client({ connection });
}

// Workflow starten
export async function startOrderWorkflow(order: Order): Promise<string> {
  const client = await getClient();
  const handle = await client.workflow.start(orderWorkflow, {
    taskQueue: 'orders',
    workflowId: `order-${order.id}`,  // Eindeutige ID — verhindert Duplikate
    args: [order],
    searchAttributes: {
      CustomKeywordField: [order.customerId],
    },
  });
  return handle.workflowId;
}

// Signal senden: Zahlung eingegangen
export async function notifyPaymentReceived(
  orderId: string,
  status: PaymentStatus
): Promise<void> {
  const client = await getClient();
  const handle = client.workflow.getHandle(`order-${orderId}`);
  await handle.signal(paymentReceivedSignal, status);
}

// Signal senden: Bestellung stornieren
export async function cancelOrder(orderId: string, reason: string): Promise<void> {
  const client = await getClient();
  const handle = client.workflow.getHandle(`order-${orderId}`);
  await handle.signal(cancelOrderSignal, reason);
}

// Query: aktuellen Status abfragen
export async function getOrderStatus(orderId: string): Promise<string> {
  const client = await getClient();
  const handle = client.workflow.getHandle(`order-${orderId}`);
  return await handle.query(orderStatusQuery);
}

// Auf Workflow-Ergebnis warten (blockierend)
export async function waitForOrder(orderId: string) {
  const client = await getClient();
  const handle = client.workflow.getHandle(`order-${orderId}`);
  return await handle.result();
}

Webhook-Handler mit Signal-Weiterleitung

Ein typisches Pattern: Ein externer Webhook (z.B. Stripe Payment-Callback) sendet ein Signal direkt an den laufenden Workflow. Claude Code generiert diesen Glue-Code vollständig mit korrekter Fehlerbehandlung.

src/api/webhookHandler.ts

import { Router } from 'express';
import { notifyPaymentReceived } from '../client/workflowClient';

const router = Router();

router.post('/webhooks/stripe', async (req, res) => {
  try {
    const event = req.body;
    if (event.type === 'payment_intent.succeeded') {
      const orderId = event.data.object.metadata.orderId;
      await notifyPaymentReceived(orderId, {
        success: true,
        paymentMethodId: event.data.object.payment_method,
        stripePaymentIntentId: event.data.object.id,
      });
    }
    res.json({ received: true });
  } catch (err) {
    res.status(500).json({ error: 'Signal delivery failed' });
  }
});

export default router;

5. Timers & Child Workflows

Temporal ermöglicht zwei mächtige Kompositionsmechanismen: workflow.sleep() für dauerhafte zeitgesteuerte Pausen und Child Workflows für die Aufteilung komplexer Prozesse in wiederverwendbare, isoliert testbare Einheiten.

TIMER

workflow.sleep() ist kein normales setTimeout. Der Timer läuft serverseitig in Temporal. Der Worker-Prozess kann währenddessen gestoppt werden — der Workflow wird nach exakt der angegebenen Zeit fortgesetzt.

src/workflows/subscriptionWorkflow.ts

import { proxyActivities, sleep, defineSignal, setHandler, condition } from '@temporalio/workflow';
import { executeChild } from '@temporalio/workflow';
import { invoiceWorkflow } from './invoiceWorkflow';
import type { SubscriptionActivities } from '../activities/subscriptionActivities';
import type { Subscription, BillingCycle } from '../types';

const { renewSubscription, sendRenewalReminder, deactivateSubscription } =
  proxyActivities<SubscriptionActivities>({
    startToCloseTimeout: '60 seconds',
    retry: { maximumAttempts: 5, initialInterval: '2 seconds', backoffCoefficient: 2 },
  });

export const cancelSubscriptionSignal = defineSignal('cancelSubscription');
export const upgradeSignal = defineSignal<[string]>('upgrade');

export async function subscriptionWorkflow(subscription: Subscription): Promise<void> {
  let cancelled = false;
  let newPlan: string | null = null;

  setHandler(cancelSubscriptionSignal, () => { cancelled = true; });
  setHandler(upgradeSignal, (plan: string) => { newPlan = plan; });

  // Endlos-Loop bis Kündigung — typisches Muster für wiederkehrende Prozesse
  while (!cancelled) {
    const cycleDuration = subscription.plan === 'annual' ? '365 days' : '30 days';

    // 7 Tage vor Ablauf: Reminder senden
    await sleep('23 days'); // bei 30-Tage-Plan
    if (cancelled) break;
    await sendRenewalReminder(subscription.id, subscription.customerEmail);

    // Restliche 7 Tage warten — oder auf Kündigung reagieren
    const cancelledDuringWait = await condition(() => cancelled, '7 days');
    if (cancelledDuringWait) break;

    // Falls Upgrade-Signal einging: Plan aktualisieren
    if (newPlan) {
      subscription = { ...subscription, plan: newPlan as any };
      newPlan = null;
    }

    // Renewal-Logic als Child Workflow (isoliert testbar, eigene History)
    const billingCycle: BillingCycle = {
      subscriptionId: subscription.id,
      plan: subscription.plan,
      customerId: subscription.customerId,
      amount: subscription.monthlyAmount,
      currency: subscription.currency,
    };

    try {
      // executeChild: wartet auf Abschluss des Child-Workflows
      const result = await executeChild(invoiceWorkflow, {
        workflowId: `invoice-${subscription.id}-${Date.now()}`,
        taskQueue: 'billing',
        args: [billingCycle],
        // Child inherits cancellation scope from parent
        cancellationType: WorkflowIdReusePolicy.AllowDuplicate,
      });
      await renewSubscription(subscription.id, result.invoiceId);
    } catch (err) {
      // Child-Workflow-Fehler behandeln ohne Parent zu beenden
      console.error('Invoice workflow failed', err);
      await renewSubscription(subscription.id, null); // Graceful degradation
    }
  }

  // Kündigung: Subscription deaktivieren
  await deactivateSubscription(subscription.id);
}

startChild vs. executeChild

Methode	Verhalten	Wann nutzen
`executeChild()`	Wartet auf Abschluss	Ergebnis wird benötigt, sequentielle Abhängigkeit
`startChild()`	Fire & forget (gibt Handle zurück)	Parallel-Ausführung, später joinen via handle.result()

src/workflows/parallelWorkflow.ts (Auszug)

import { startChild } from '@temporalio/workflow';

// Mehrere Child-Workflows parallel starten
const [invoiceHandle, analyticsHandle, notificationHandle] = await Promise.all([
  startChild(invoiceWorkflow, { workflowId: `inv-${id}`, args: [billingData] }),
  startChild(analyticsWorkflow, { workflowId: `anl-${id}`, args: [eventData] }),
  startChild(notificationWorkflow, { workflowId: `ntf-${id}`, args: [notifData] }),
]);

// Auf alle drei Ergebnisse warten
const [invoice, analytics, notification] = await Promise.all([
  invoiceHandle.result(),
  analyticsHandle.result(),
  notificationHandle.result(),
]);

6. Worker & Production-Setup

Der Temporal Worker ist der Prozess der tatsächlich Workflows und Activities ausführt. Worker pollen kontinuierlich die Temporal Task Queue und führen die zugewiesenen Tasks aus. Mehrere Worker können parallel laufen — Temporal verteilt die Last automatisch.

WORKER

Ein Worker registriert Workflows und Activities bei Temporal und pollt dann seine Task Queue. Horizontal skalierbar: einfach mehr Worker-Prozesse starten.

src/worker.ts

import { Worker, NativeConnection, Runtime } from '@temporalio/worker';
import { Connection } from '@temporalio/client';
import * as orderActivities from './activities/orderActivities';
import * as subscriptionActivities from './activities/subscriptionActivities';
import { metrics } from './monitoring/metrics';

async function run(): Promise<void> {
  // Runtime mit Prometheus-Metriken konfigurieren
  Runtime.install({
    telemetryOptions: {
      metrics: {
        prometheus: {
          bindAddress: process.env.METRICS_BIND_ADDRESS ?? '0.0.0.0:9464',
        },
      },
      logging: {
        forward: { level: 'DEBUG' },
      },
    },
  });

  // Verbindung zum Temporal-Server (lokal oder Temporal Cloud)
  const connection = await NativeConnection.connect({
    address: process.env.TEMPORAL_ADDRESS ?? 'localhost:7233',
    // Für Temporal Cloud: TLS + Namespace angeben
    tls: process.env.TEMPORAL_TLS_CERT ? {
      clientCertPair: {
        crt: Buffer.from(process.env.TEMPORAL_TLS_CERT, 'base64'),
        key: Buffer.from(process.env.TEMPORAL_TLS_KEY!, 'base64'),
      },
    } : undefined,
  });

  // Worker erstellen
  const worker = await Worker.create({
    connection,
    namespace: process.env.TEMPORAL_NAMESPACE ?? 'default',
    taskQueue: 'orders',

    // Workflow-Bundles via Webpack-Bundle-Pfad (kein direkter Import!)
    workflowsPath: require.resolve('./workflows'),

    // Activities direkt importieren
    activities: {
      ...orderActivities,
      ...subscriptionActivities,
    },

    // Concurrency-Konfiguration
    maxConcurrentActivityTaskExecutions: 100,
    maxConcurrentWorkflowTaskExecutions: 40,

    // Interceptors für Tracing/Logging
    interceptors: {
      workflowModules: [require.resolve('./interceptors/workflowInterceptor')],
      activityInbound: [() => new ActivityMetricsInterceptor(metrics)],
    },

    // Graceful Shutdown
    shutdownGraceTime: '30 seconds',
  });

  // Graceful Shutdown bei SIGTERM (z.B. Kubernetes Pod-Termination)
  process.on('SIGTERM', () => worker.shutdown());
  process.on('SIGINT', () => worker.shutdown());

  console.log('Worker started, polling task queue: orders');
  await worker.run();
}

run().catch((err) => {
  console.error('Worker failed', err);
  process.exit(1);
});

Temporal Cloud vs. Self-Hosted

Aspekt	Temporal Cloud	Self-Hosted
Setup	Sofort, kein Ops-Aufwand	Kubernetes + Cassandra/PostgreSQL nötig
Kosten	Action-basiert (~$25/Mio. Actions)	Infra-Kosten + Ops-Zeit
SLA	99.99% Uptime garantiert	Eigene Verantwortung
Compliance	SOC 2, GDPR-konform	Volle Datenkontrolle
Empfehlung	Startups & Teams <50 Engineers	Große Unternehmen mit Compliance-Anforderungen

Deployment mit Docker Compose

docker-compose.temporal.yml

version: '3.8'
services:
  temporal:
    image: temporalio/auto-setup:1.24
    environment:
      - DB=postgresql
      - DB_PORT=5432
      - POSTGRES_USER=temporal
      - POSTGRES_PWD=temporal
      - POSTGRES_SEEDS=postgres
    ports:
      - "7233:7233"
    depends_on: [postgres]

  temporal-ui:
    image: temporalio/ui:2.26
    environment:
      - TEMPORAL_ADDRESS=temporal:7233
    ports:
      - "8233:8233"

  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: temporal
      POSTGRES_USER: temporal
    volumes:
      - temporal-db:/var/lib/postgresql/data

  worker:
    build: .
    command: node dist/worker.js
    environment:
      - TEMPORAL_ADDRESS=temporal:7233
      - DATABASE_URL=postgresql://temporal:temporal@postgres:5432/app
    depends_on: [temporal]
    deploy:
      replicas: 3  # Einfach horizontal skalieren

volumes:
  temporal-db:

Monitoring-Metriken

Temporal exportiert Prometheus-Metriken out-of-the-box. Wichtigste KPIs für Production-Monitoring:

temporal_workflow_task_schedule_to_start_latency

Wartezeit bis ein Workflow-Task von einem Worker aufgenommen wird. Hoch = zu wenige Worker.

temporal_activity_schedule_to_start_latency

Wartezeit bis eine Activity gestartet wird. Korreliert direkt mit User-Wahrnehmung.

temporal_workflow_failed_total

Anzahl fehlgeschlagener Workflows (nach allen Retries). Alert wenn Rate steigt.

temporal_activity_execution_failed_total

Fehlgeschlagene Activity-Versuche. Normal wenn Retries aktiv, alarmierend wenn nonRetryable.

Determinismus-Fehler sind die häufigste Temporal-Falle: Wenn Workflow-Code verändert wird während Workflows noch laufen, kann es zu History-Mismatch-Fehlern kommen. Lösung: Versioned Workflows mit patched()-API oder neue Workflow-Definitionen per Major-Version einführen.

Claude Code als Temporal-Entwicklungspartner

Claude Code versteht Temporals Determinismus-Regeln und den Unterschied zwischen Workflow- und Activity-Code instinktiv. Typische Aufgaben die Claude Code in Minuten erledigt:

Workflow-Skeleton generieren aus einer Business-Anforderung in natürlicher Sprache
Activities extrahieren aus bestehendem Code der direkt I/O macht
Retry-Policies konfigurieren basierend auf Activity-Charakteristik (transient vs. permanent)
Signal & Query-Handler für komplexe State-Machines automatisch erzeugen
Child-Workflow-Topologien für hierarchische Business-Prozesse designen
Test-Suites mit Temporal Test Suite schreiben (Mock-Activities, deterministische Zeittests)
Migration-Strategies für Breaking Changes in laufenden Workflows entwickeln

Beispiel-Prompt für Claude Code:

"Implementiere einen Temporal-Workflow für einen SaaS-Onboarding-Prozess: User registriert sich → Email-Verifikation (Timeout 48h) → Trial-Account anlegen → Willkommens-Email → nach 14 Tagen Trial-Ablauf-Reminder → nach 30 Tagen Downgrade falls kein Upgrade. Activities und Workflow trennen, nonRetryable Errors definieren."

Claude Code generiert daraus vollständig funktionierenden TypeScript-Code mit korrekter Activity-Trennung, Timeout-Konfiguration, Signal-Handlern und sogar Unit-Tests mit der Temporal Test Suite — in einem einzigen Prompt.

Temporal-Workflows mit Claude Code bauen?

Probiere unseren KI-gestützten Entwicklungs-Trial: Temporal-Workflows, Activities, Signals und Worker-Konfiguration — Claude Code unterstützt deinen Stack.

Kostenlos starten →

Temporal mit Claude Code:Resiliente Workflows 2026