Deadline-gebundene Batch-Berechnung: so garantieren Sie die Einhaltung

„Muss bis zum 5. des nächsten Monats fertig sein, sonst kommen die Provisionen zu spät und die Verkäufer drehen durch.“ Das ist deadline-gebundener Batch — es reicht nicht, dass er einmal fertig wird; er muss immer, pünktlich, auch bei 40 % Datenwachstum dieses Jahres fertig werden.

Gleiches gilt für Payroll (Gesetz schreibt Auszahlung in X Tagen vor), Monatsabschluss, Rechnungszyklen, Regulatory-Reporting. Wenn Sie dort sind, so geht's.

1. Messen, nicht schätzen

Schritt eins: Wie lange dauert die Berechnung auf echten Daten, und wie skaliert sie. Nicht „sollte passen“. Konkrete Zahlen.

Für JUST gemessen:

• 1 000 Verkäufer × Provisionen = 12 Sekunden
• 3 000 Verkäufer = 38 Sekunden (überlinear — O(N log N) irgendwo innen)
• 10 000 Verkäufer = 5,5 Minuten (Extrapolation)
• Erwartetes Wachstum in 3 Jahren: 1 000 → 8 000 Verkäufer

In 3 Jahren würde der Lauf 3 Minuten dauern. Deadline 5 Tage, 3 Minuten passen. Aber bei Wachstum 1 000 → 30 000 wären es 30+ Minuten, und wenn der Lauf Downstream-Abhängigkeiten hat (Bank-Rechnungserzeugung), wird's eng.

Upfront messen = realistische Sicht. Ohne Messung entwerfen Sie für heute, und in einem Jahr haben Sie einen Bug.

2. Auf Ebene unabhängiger Einheiten parallelisieren

Batch-Berechnung ist typischerweise ein Loop über N Items, wobei jedes unabhängig ist. Für JUST ist ein Verkäufer = eine unabhängige Berechnungseinheit. Ergebnisse hängen nicht davon ab, was ein anderer Verkäufer macht (außer Downline-Overrides, die in ein eigenes Preprocessing gehen).

Architektur:

• Preprocessing: Daten validieren, Kontext vorbereiten
• Partition: Verkäufer in N Batches aufteilen (z. B. 100 Batches à 80 bei 8 000 Verkäufern)
• Parallel Execute: N Worker, jeder bearbeitet seinen Batch unabhängig
• Aggregate: Ergebnisse zum Endreport zusammenführen

Für JUST liefen 10 Parallel-Worker auf Azure Functions (später 20). Skalierung war nahezu linear, bis wir an den DB-Connection-Pool stießen.

3. Deadline-Monitoring mit Pre-Alerting

Lauf startet am 1. des Monats. Deadline 5. Am 5. zu prüfen, ob er's schafft, ist zu spät. Stattdessen:

• Tag 1, Stunde 0: Batch-Start
• Tag 1, Stunde 2: wenn noch nicht fertig, informativer Pre-Alert
• Tag 1, Stunde 6: High-Priority-Alert (etwas ist ernsthaft langsam)
• Tag 2, Stunde 0: Eskalation (Human Intervention)
• Tag 3: Rollback-Plan, manuelle Berechnung etc.

Pre-Alerting gibt 3-4 Tage Puffer zur Diagnose und Fix. Ohne das merken Sie es am 5. früh, und es ist zu spät.

4. Idempotenter Retry + Checkpoint

Batch stürzt in der Mitte ab. Was jetzt? Zwei Extreme:

• Von vorn starten — einfach, aber bei einem 30-Min-Lauf 30 Minuten Verzögerung
• Vom letzten Checkpoint fortsetzen — komplexer, spart Zeit

Für deadline-gebundene Systeme sind Checkpoints Pflicht. Nach jedem Batch wird eine batch_progress-Zeile geschrieben (batch_id, completed_sellers, timestamp). Beim Retry wird der letzte Checkpoint geladen und weitergemacht.

Kritisch: Per-Verkäufer-Berechnung muss idempotent sein. Zweimal ausgeführt liefert dasselbe Ergebnis. Das stellen Sie sicher, indem DB-Writes als UPSERT auf (seller_id, month) passieren.

5. Vollständiger Dry-Run auf echter Datenkopie vor Produktion

Staging-Test mit 100 Verkäufern sagt nichts über Verhalten mit 10 000. Vor jedem Quartal machen wir einen vollständigen Dry-Run auf einer Produktions-Daten-Kopie:

• Produktions-DB ins Staging klonen
• Batch end-to-end laufen lassen
• Ergebnisse mit Produktions-Historie vergleichen
• Timing messen — entspricht es dem Wachstumsmodell?

3× im letzten Jahr hat der Dry-Run ein Problem aufgedeckt, bevor es in Produktion kam — einmal Memory-Leak, zweimal N+1-Query-Bug, der die Laufzeit 10× aufgebläht hätte.

6. Degradation-Strategy für Edge-Cases

Was, wenn Daten korrupt sind und die Berechnung für den ganzen Batch blockieren? Zwei Strategien:

• Fail-fast: erster Fehler stoppt Batch, Human Intervention
• Skip-and-log: problematischer Verkäufer übersprungen, Batch läuft weiter, Fehler geloggt für Nachbearbeitung

Wahl hängt vom Business-Kontext ab. Für Provisionen ist Fail-fast unsinnig — 5 Verkäufer mit kaputten Daten würden bedeuten, 10 000 andere bekommen kein Geld. Skip-and-log ist besser — alle zahlen außer jene 5, die manuell gelöst werden.

JUST-Ergebnis

Nach 3 Betriebsjahren:

• Verkäufer-Anzahl wuchs von 2 800 auf 6 200 (+120 %)
• Monats-Provisionslauf: früher ~8 min, jetzt ~14 min (skaliert gut)
• 0 verpasste Deadlines in 3 Jahren
• 2 Vorfälle, bei denen Pre-Alert 4-6 Stunden nach Start eingriff, Behebung vor Deadline ohne Stress

Verallgemeinerung

Deadline-gebundener Batch ist ein häufiges Muster und wird trotzdem meist ad-hoc gebaut. Die Regeln wiederholen sich:

• Messen, nicht schätzen
• Auf Ebene unabhängiger Einheiten parallelisieren
• Pre-Alerting auf mehreren Zeithorizonten
• Idempotenter Retry + Checkpoint fürs Resume
• Dry-Run auf echter Datenkopie vor jedem kritischen Zyklus
• Degradation-Strategy für Edge-Cases

Payroll, Monatsabschluss, Regulatory-Reports, Clearing-Cycles, Billing-Runs — alles Deadline-Batch. Wenn Sie in einem dieser Bereiche sind und Ihre Pipeline weniger als 4 dieser 6 Punkte erfüllt, ist es eine Frage wann, nicht ob, eine Deadline reißt.