GH GambleHub

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.
SLO (exemple) :
  • 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é)

`schedule` `{id, tenant, region, tz, croncalendar, window, enabled, owner, policy_version}`
`job` `{id, schedule_id?, type, payload_hash, idempotency_key, priority, must_start_by, attempts, status, receipt_hash}`
`lease` `{job_id, worker_id, acquired_at, ttl}`
`run_log` `{job_id, started_at, finished_at, outcome, trace_id, metrics{}, receipts[]}`
`dlq_item` `{job_id, reason, attempts, last_error, owner_notified}`

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

ZoneRACI
Architecture du planificateurPlatform/SRECTOData, SecurityProduct
Politiques/SoD/calendrierCompliance/IAMCCO/CISOLegal, OpsTout
Observabilité/SLOSREHead of EngData, FinOpsSupport
Économie/quotasFinOpsCFO/CTOSRE, ProductBU Leads
Les playbooks critiquesIR TeamCOOPartners, LegalAudit

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.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.