„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.