Planer und Hintergrundaufgaben

(Abschnitt: Operationen und Management)

1) Ernennung

Scheduler und Background-Tasks ermöglichen den Off-User-Betrieb der Plattform: periodische Berechnungen, Artefaktveröffentlichungen, Clearing und Warteschlangenreplikationen. Die Ziele sind Determiniertheit, Störfestigkeit und Prüfbarkeit.

2) Taxonomie der Aufgaben

Zeitbasiert: nach Zeitplan (cron/Kalender): Clearing, Schließen von RTP-Fenstern, Uploads, Archivierung.
Event-driven: Trigger aus dem Bus (PaymentsSettled, PriceListUpdated).
One-off/Ad-hoc: Einmalige Jobs mit TTL.
Langstreckenlauf: Backoff/Sagas, Streaming-Compakschen.
Wartung: Schlüsselrotationen, Wiederholungen, Indizes, Cache-Aufwärmen.

3) Architektur (Referenz)

1. Scheduler (control-plane): speichert Zeitpläne, CAL/cron, Wartungsfenster, Zeitzonen, Limiter.

2. Dispatcher: Plan → Warteschlange (per-priority/tenant/region), setzt Fristen, idempotente Schlüssel.

3. Workers: Statisch/autoscale unter Aufgabenpools; heartbeats, leases.

4. Queue/Bus: FIFO/Priorisierung, DLQ, verzögerte Nachrichten.

5. Locker/Koordination: Verteilte Sperren (Leases), Leader-Election (Floß/ZK/Consul).

6. Vault/KMS: JIT-Geheimnisse, kurze TTLs.

7. Observability: traces/metrics/logs, dashboards, alerts.

8. Audit/WORM: unveränderliche Ausführungsbelege, Merkle-Slices.

Muster: outbox/CDC, idempotency, compensation (saga), backpressure, circuit-breakers.

4) Fahrpläne: cron und Kalender

Cron v3: Sekunde/Minute/Stunde/Tag/Monat/Wochentag; Unterstützung für „/5 “, Bereiche, Listen.
Kalender/Ausnahmen: Geschäftskalender, „Fenster der Stille“, Feiertage/DST.
Zeitzonen: Speichern Sie' tz' auf der Aufgabe; Starten der lokalen Zeit des Tenants.
Multiregion: Kopien von Fahrplänen pro Region oder „leading region + followers“ mit Drift/Wiederwahl.

5) Warteschlangen, Prioritäten, SLA

Prioritätsklassen: P0 (kritisch), P1, P2, P3; separate Pools von Workern.
SLA/Deadlines: „must _ start _ by“, „must _ finish _ by“; pass - Eskalation/Rückzug.
Quoten und Fairness: Caps auf Aufgaben/min/Tenant, Tokens auf „Bursts“, Isolation von Noisy-Nachbarn.
Verzögerte Aufgaben: „nicht vor“ (delay/visibility timeout).

6) Wettbewerb und Blockaden

Leases: Arbeitsmiete mit Auto-Verlängerung (Herzschlag); durch Auszeit - Wiederkehr.
Mutex/Semaphore: per-Ressource (z.B. „Preisliste x schreibt nur einen Worker“).
Sharding: durch „tenant/region/hash (key)“; Sticky-Routing für Cache und Datenlokalität.
Leader-Election: Ein Leader veröffentlicht „System“ -Jobs (z.B. „alle RTP-Fenster schließen“), Follower sind Hot Standby.

7) Zuverlässigkeit: Retrays, Idempotenz, Dedup

Der idempotente Schlüssel: „(task_type, business_id, Fenster)“; Wiederholungen → die gleiche Quittung.
Retrays: exponentielle Backoffs + Jitter, Limit-Versuche, On-Error-Strategie (Retry/Cancel/Compensate).
Poison-pill: schnelle Übersetzung in DLQ nach N Abstürzen, alert an den Besitzer.
Dedup: seen-cache (in-memory + KV) auf der TTL des Fensters.
Exactly-once Effekte: Bestätigung der Nebenwirkungen durch Transaktionsprotokoll/Quittungen.

8) Verwaltung langer und schwerer Aufgaben

Chunking: Aufschlüsselung in Batches, Checkpoints/Fortsetzung.
Zeit-Boxen: CPU/IO/Netzwerk egress Einschränkung; Unterbrechung unter Beibehaltung des Fortschritts.
Sagas/Kompensationen: „Undo“ -Semantik für serviceübergreifende Schritte.
Concurrency-caps: Grenzen gleichzeitiger Aufgaben pro Typ/Tenant/Region.

9) Beobachtbarkeit und Metriken

Traces: 'trace _ id', Saga-Schritte, externe Herausforderungen.

• Lag bis zum Start, Warteschlange (Länge, Alter p95).
• Success Rate, error-rate, retry-rate.
• Latency p50/p95, time-to-complete.
• Kosten pro 1k Aufgaben, egress/ingress.
• DLQ rate, poison-pill rate.

• P0 Start ≤ 60 s, P1 ≤ 5 min; Success ≥ 99. 5%; DLQ ≤ 0. 1%; Freshness (Operschina) ≤ 30 mit p95.

10) Auditierung und Nachweisbarkeit

Quittungen: 'receipt _ hash' für Start/Erfolg/Fehler, DSSE-Signaturen für kritische Typen (Zahlungen, Preislisten, RTP).
WORM: Speichern von Ausführungsprotokollen und Aufgabenmanifests.
Chain-of-custody: wer hat den Zeitplan festgelegt/genehmigt/geändert; SoD-Prüfungen.

11) Sicherheit und Zugänge

RBAC/ABAC/ReBAC: wer erstellt/genehmigt/startet; SoD: „Zahlung erstellen“ ≠ „genehmigen“.
JIT-Geheimnisse: Ein Worker fordert Token mit einer kurzen TTL an, um eine Aufgabe zu lösen.
Isolierung: per-tenant/region/mesh worker pools; Sandbox-Ausführung.
PII-Hygiene: Maskierung/Tokenisierung, Verbot der Protokollierung des Primary.

12) FinOps und Kosten

Budgets/cap alert auf compute/storage/egress.
Auto-Scale-Worker in Warteschlangen und SLOs.
Speicherklassen: heiß (7-30 Tage) → OLAP (6-24 Monate) → Archiv.
Cost-aware-Planung: Startfenster in der „billigen Uhr“, Limits auf egress.

13) Datenmodell (vereinfacht)

14) API-Verträge (Management/Integration)

'POST/schedules' - Erstellen Sie einen Zeitplan (cron/cal, tz, Fenster).
„POST/jobs“ - ad-hoc; gibt 'job _ id', 'receipt _ hash' zurück.
„GET/jobs/{ id}“ - Status/Protokoll/Quittungen.
„POST/jobs/{ id }/cancel“ - Stornierung mit Entschädigung.
„GET/queues/stats“ - Längen, Lags, p95.
Вебхуки: `JobStarted`, `JobSucceeded`, `JobFailed`, `JobDroppedToDLQ`, `SLOViolated`.

15) Playbooks (typische Szenarien)

Retry-Storm: Aktivieren Sie globale Backoffs, erhöhen Sie Abhängigkeitszeiträume, aktivieren Sie Circuit-Breaker, teilen Sie Schlachten.
DLQ-Lawine: Empfang stoppen, DLQ-Analyse priorisieren, neue Aufgaben puffern.
Der Anführer ist gefallen: Wiederwahl, Verifizierung von „Doppelpublikationen“ nach Idempotenz, Audit.
Zavis Provider (PSP/KYC): Route auf Reserve, reduzieren Sie die Häufigkeit von Polling/Webhooks, übertragen Sie Transaktionen in Quarantäne.
Durchgesickerte Worker-Geheimnisse: Schlüsselrückruf, Rotation, Suche nach „abnormalen“ Starts in 30 Tagen, Revue passieren lassen.

16) Besonderheiten von iGaming/Fintech

Zahlungen/Auszahlungen: asynchrone Jobs mit Quittungen, Quarantäne von „grauen“ Transaktionen, Replikationen von Warteschlangen mit Deduplikaten.
RTP-Fenster/Limits: Schließung nach Kalender, beobachtete vs theoretische RTP, Auto-Pause Promo beim Driften.
Preislisten/FX/Tax: geplante Veröffentlichungen, Versionen von Artefakten, höhere Behinderung des Cache.
Affiliates: Konversionsabgleich, Webhooks-Dedup, Acts/Signaturen, Treuhandstreitigkeiten.

17) Qualitätsmetriken (Beispielsatz)

Schedule Adherence: Der Anteil der Aufgaben der Starter im Fenster ≥ 99%.
Queue Lag p95: P0 ≤ 60 c, P1 ≤ 5 min.
Success/Retry/DLQ Rate: ≥ 99. 5% / ≤ 0. 4% / ≤ 0. 1%.
Idempotency Errors: ≤ 0. 01%.
Cost/1k Jobs und Egress/Job - innerhalb des Budgets.
Audit Completeness: 100% kritische Aufgaben mit Quittungen.

18) RACI

19) Checkliste Umsetzung

• Hervorhebung von Aufgabenklassen, Prioritäten und SLAs; Kalender und Zeitzonen definieren.
• Stellen Sie Scheduler/Dispatcher/Queue/Workers mit Leader-Election und Sharding bereit.
• Einführung von Idempotenz, Retrai, DLQ, Kompensation (Saga).
• Konfigurieren Sie RBAC/ABAC/ReBAC, SoD und JIT-Geheimnisse für Worker.
• traces/metrics/logs, Dashboards und Alerts einschließen; SLO и error-budget.
• Signierte Quittungen (DSSE) und WORM-Protokolle für kritische Typen.
• Autoscale und Cap Alerts nach Kosten (compute/storage/egress).
• Playbooks: Retry-Storm, DLQ-Lawine, Leaderversagen, Anbieterdegradierung.
• Tests: GameDay für jedes Playbook, Injektionen von Verzögerungen/Fehlern.
• Regelmäßige Reviews von Zeitplänen, Warteschlangenblockaden und Automatisierungs-ROIs.

20) FAQ

Warum ist cron nicht genug?
Ohne Warteschlangen, Idempotenz, Sperren und Audits bricht cron bei Ausfällen und Zeitzonen zusammen.

Kann man zeitbasiert und ereignisgetrieben kombinieren?
Ja: cron - Versicherung für catch-up; Ereignisse - für Reaktivität.

Wie erreicht man „genau einmal“?
Dedup nach Schlüssel, transaktionales Effektprotokoll, Quittungen und idempotente Nebenwirkungen.

Was tun mit „langen“ Jobs?
Chunk, Checkpoints, Zeitboxen, Möglichkeit zu unterbrechen und fortzufahren.

Wie kann man ein Budget nicht „essen“?
Auto-Scale durch Warteschlangen und SLOs, billige Uhren für schwere Jobs, harte Egress/Compute-Caps.

Zusammenfassung: Der Planer und die Hintergrundaufgaben sind die Produktionspipeline der Plattform. Durch die Einbettung von Zeitplänen und Warteschlangen, Idempotenz, Sperren und Überwachbarkeit, das Hinzufügen von Quittungen/Audits, Tenant-Isolation und FinOps-Kontrolle erhalten Sie vorhersehbare Laufzeiten, schnelle Recovery und rechtlich gestützte Operationen in allen Regionen und Lasten.