Planificateur et tâches d'arrière-plan
(Section : Opérations et gestion)
1) Destination
Le planificateur et les tâches d'arrière-plan assurent le fonctionnement hors utilisateur de la plate-forme : calculs périodiques, publications d'artefacts, compensation et relais de file d'attente. Les objectifs sont la déterminisme, la résistance aux défaillances et l'audit.
2) Taxonomie des tâches
Time-based : programmé (cron/calendrier) : compensation, fermeture des fenêtres RTP, déchargement, archivage.
Event-driven : déclencheurs du bus (PaymentsSettled, PriceListUpdated).
One-off/Ad-hoc : jobs uniques avec TTL.
Long-running : bacof/sagas, compacts de streaming.
Maintenance : rotations de clés, repérage, index, échauffement du cache.
3) Architecture (référence)
Composants :1. Scheduler (control-plane) : stocke les horaires, CAL/cron, fenêtres de service, temporisateurs, limiteurs.
2. Dispatcher : plan → file d'attente (per-priority/tenant/region), appose des deadlines, clés idempotent.
3. Workers : statique/auto-skate sous les pools de tâches ; heartbeats, leases.
4. Queue/Bus : FIFO/priorisation, DLQ, messages différés.
5. Locker/Coordination : verrous distribués (leases), election leader (Raft/ZK/Consul).
6. Vault/KMS : Secrets JIT, court TTL.
7. Observability : traces/metrics/logs, dashboards, alertes.
8. Audit/WORM : reçus d'exécution immuables, tranches Merkle.
Patterns : outbox/CDC, idempotency, compensation (saga), backpressure, circuits-breakers.
4) Horaires : cron et calendriers
Cron v3 : seconde/minute/heure/jour/mois/jour-semaine ; support « /5 », fourchettes, listes.
Calendriers/exceptions : calendrier d'affaires, « fenêtres de silence », jours fériés/DST.
Timesons : gardez 'tz' sur la tâche ; démarrage à l'heure locale du tenant.
Multiregion : copies des horaires par région ou « région principale + followers » avec drain/réélection.
5) Files d'attente, priorités, SLA
Classes de priorité : P0 (critique), P1, P2, P3 ; pools distincts de worker.
SLA/debline : 'must _ start _ by', 'must _ finish _ by' ; le laissez-passer est une escalade/rétraction.
Quotas et fairness : caps pour les tâches/min/tenant, tokens pour les « burst », isolation noisy-neighbors.
Tâches retardées : « pas avant » (delay/visibility timeout).
6) Concurrence et verrouillage
Leases : location de travaux avec auto-extension (heartbeat) ; par timing - réédition.
Mutex/sémaphores : par ressource (par exemple, « la liste de prix x n'écrit qu'un seul worker »).
Chardonnages : par 'tenant/region/hash (key)' ; sticky-routing pour le cache et la localisation des données.
Leader-election : un leader publie des jobs « système » (par exemple, « fermer toutes les fenêtres RTP »), les followers sont un standby chaud.
7) Fiabilité : Retrai, idempotence, dedup
Clé idempotent : '(task_type, business_id, window)' ; répétitions → même reçu.
Retrai : exponentielle back-off + gitter, limite de tentative, stratégie on-error (retry/cancel/compensate).
Poison-pill : transfert rapide au DLQ après N pannes, alert au propriétaire.
Dedup : seen-cache (in-memory + KV) sur la fenêtre TTL.
Effets exactly-once : confirmation des effets secondaires par le biais du journal transactionnel/reçus.
8) Gérer les tâches longues et lourdes
Chunking : ventilation en batchi, chekpoints/suite.
Time-boxing : limitation de CPU/IO/egress réseau ; interruption avec maintien des progrès.
Sagi/compensation : sémantique « undo » pour les étapes interservices.
Concurrency-caps : limites des tâches simultanées par type/tenant/région.
9) Observabilité et métriques
Traces : 'trace _ id', étapes de la saga, appels externes.
Metrics (SLI):- Lag avant le départ, file d'attente (longueur, âge p95).
- Success Rate, error-rate, retry-rate.
- Latency p50/p95, time-to-complete.
- Cost per 1k tâches, egress/ingress.
- DLQ rate, poison-pill rate.
- P0 départ ≤ 60 s, P1 ≤ 5 min ; Success ≥ 99. 5%; DLQ ≤ 0. 1%; Freshness (Opershina) ≤ 30 s p95.
10) Audit et probabilité
Reçus : 'receipt _ hash' pour le démarrage/succès/erreur, signatures DSE pour les types critiques (paiements, listes de prix, RTP).
WORM : stocke les logs d'exécution et les manifestes de tâche.
Chain-of-custody : qui a mis/approuvé/modifié l'horaire ; Vérification SoD.
11) Sécurité et accès
RBAC/ABAC/ReBAC : qui crée/approuve/lance ; SoD : « créer un paiement » ≠ « approuver ».
Secrets JIT : Le voleur demande des jetons avec un court TTL sur l'ensemble de la tâche.
Isolation : pools de workers per-tenant/region/maillage ; sandbox-exécution.
Hygiène PII : masquage/tokenization, interdiction de la logique primaire.
12) FinOps et coût
Budgets/cap-alerts sur compute/storage/egress.
Auto-Skale Worker sur les files d'attente et SLO.
Classes de stockage : chaud (7-30 jours) → OLAP (6-24 mois) → archive.
Planification cost-aware : fenêtre de démarrage en « heures bon marché », limites sur egress.
13) Modèle de données (simplifié)
14) API contrats (gestion/intégration)
'POST/schedules ': crée un planning (cron/cal, tz, fenêtres).
« POST/jobs » - mettre ad hoc ; retourner 'job _ id', 'receipt _ hash'.
« GET/jobs/{ id} » est le statut/journal/reçu.
'POST/jobs/{ id }/cancel 'est une annulation compensatoire.
'GET/queues/stats 'est la longueur, la lagune, p95.
Вебхуки: `JobStarted`, `JobSucceeded`, `JobFailed`, `JobDroppedToDLQ`, `SLOViolated`.
15) Pleybooks (scénarios types)
Retry-storm : activer le back-off global, augmenter les temps de dépendance, activer le circuit-breaker, écraser les trampolines.
DLQ-avalanche : arrêter la réception, hiérarchiser l'analyse du DLQ, tamponner de nouvelles tâches.
Le leader est tombé : réélection, vérification des « doubles publications » sur l'idempotence, audit.
Zavis du fournisseur (PSP/KYC) : route vers la réserve, réduire la fréquence de polling/webhooks, mettre les transactions en quarantaine.
Fuite des secrets de worker : retrait des clés, rotation, recherche de lancements « anormaux » en 30 jours, je rummage des droits.
16) Spécificité iGaming/fintech
Paiements/décaissements : jobs asynchrones avec reçus, mise en quarantaine des transactions « grises », repli des files d'attente avec dédupit.
Fenêtre RTP/limites : fermeture par calendrier, RTP théorique observé par vs, auto-pause promo à la dérive.
Listes de prix/FX/Tax : publications programmées, versions d'artefacts, cache de force handicapé.
Affiliation : rapprochement des conversions, dedup de webhooks, actes/signatures, contrefaçon de litiges.
17) Métriques de qualité (exemple de jeu)
Schedule Adherence : proportion de tâches qui ont démarré dans la fenêtre ≥ 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 et Egress/job - dans les limites du budget.
Audit Completeness : 100 % des tâches critiques avec des reçus.
18) RACI
19) Chèque de mise en œuvre
- Mettre en évidence les classes de tâches, les priorités et les SLA ; définir les calendriers et les temporisations.
- Déployer Scheduler/Dispatcher/Queue/Travailleurs avec election leader et chardonnages.
- Introduire idempotentialité, rétroactivité, DLQ, compensation (saga).
- Configurer les secrets RBAC/ABAC/ReBAC, SoD et JIT pour les workers.
- Inclure traces/metrics/logs, dashboards et alerts ; SLO и error-budget.
- Reçus signés (DSE) et journaux WORM pour les types critiques.
- Auto Skale et Cap Alert au coût (compute/storage/egress).
- Pleybooks : retry-storm, DLQ-avalanche, refus du leader, dégradation du fournisseur.
- Tests : GameDay pour chaque pleybuck, injections de retards/erreurs.
- Je revois régulièrement les horaires, les blocages de file d'attente et l'automatisation ROI.
20) FAQ
Pourquoi le cron ne suffit-il pas ?
Sans files d'attente, idempotence, blocages et audits, cron se casse sur les pannes et fuseaux horaires.
Puis-je combiner time-based et event-driven ?
Oui : cron est une assurance catch-up ; les événements sont pour la réactivité.
Comment faire exactement une fois ?
Dedup par clé, journal transactionnel des effets, reçus et effets secondaires idempotent.
Que faire des jobs « longs » ?
Chunk, chekpoints, time-boxing, possibilité d'interrompre et de continuer.
Comment ne pas « manger » le budget ?
Auto-skate par files d'attente et SLO, horloge bon marché pour les jobs lourds, hard egress/compute.
Résumé : Le planificateur et les tâches de fond sont le pipeline de production de la plate-forme. En intégrant les horaires et les files d'attente, l'idempotence, les verrous et l'observabilité, en ajoutant des reçus/audits, l'isolation des tenants et le contrôle FinOps, vous obtiendrez des délais prévisibles, une récupération rapide et des opérations légalement résistantes dans toutes les régions et toutes les charges.