GH GambleHub

Pianificazione e attività di sfondo

(Sezione Operazioni e Gestione)

1) Destinazione

Pianificatore e attività di background forniscono operazioni esterne alla piattaforma: calcoli periodici, pubblicazioni di manufatti, clearing e repliche di code. Gli obiettivi sono la determinazione, la resistenza ai guasti e l'audio.


2) Tassonomia delle attività

Time-based - Pianificato (cron/calendario) - Clearing, chiusura delle finestre RTP, caricamento, backup.
Event-driven: trigger da pneumatico (PaymentsSettled, PriceListUpdated).
One-off/Ad-hoc: job singole con TTL.
Long-running - bacof/saghe, compagini di streaming.
Maintenance: rotazioni delle chiavi, repakage, indici, riscaldamento della cache.


3) Architettura (arbitro)

Componenti:

1. Scheduler (control-plane) - Memorizza pianificazioni, CAL/cron, finestre di manutenzione, timsons, limitatori.

2. Dispatcher: piano coda (per-priority/tenant/region), inserisce deadline, chiavi idimpotenti.

3. Workers: scale statico/automatico sotto i pool di task; heartbeats, leases.

4. Queue/Bus: FIFO/Prioring, DLQ, messaggi posticipati.

5. Locker/Coordinamento - Blocchi distribuiti (leases), leader elettrico (Raft/ZK/Consul).

6. Vault/KMS: segreti JIT, TTL brevi.

7. Osservabilità: traces/metrics/logs, dashboard, alert.

8. Check/WORM - Ricevute di esecuzione invariate, tagli Merkle.

Pattern: outbox/CDC, idempotency, compensi (saghe), backpressure, circuiti-breakers.


4) Pianificazioni: cron e calendari

Cron v3: secondo/minuto/ora/giorno/mese/giorno/settimana; supporta «/5 », intervalli, elenchi.
Calendari/eccezioni: calendario aziendale, finestre di silenzio, vacanze/DST.
Timsons: memorizza «tz» nell'attività; Avvia l'ora locale del tenente.
Multi-region: copie di pianificazioni per-region o «regione guida + followers» con ruota/rielezione.


5) Code, priorità, SLA

Classi di priorità: P0 (critica), P1, P2, P3; singoli pool di worker.
SLA/deadline: 'must _ start _ by', 'must _ finish _ by'; pass - escalation/retrai.
Quote e fairness: caps per attività/min/tenant, token per «burst», isolamento noisy-neighbors.
Attività posticipate: «non prima» (delay/visibility timeout).


6) Concorrenza e blocchi

Leases - noleggio lavoro con rinnovo automatico (heartbeat); timeout - Rielezione.
Mutex/semaforo: per-risorsa (ad esempio, «preice-foglia x scrive solo un worker»).
Sharding: «tenant/region/hash (key)»; sticky-routing per la cache e la localizzazione dei dati.
Leader elettrico: un leader pubblica i jobs di sistema (ad esempio, «chiudere tutte le finestre RTP»), i followers sono standby hot.


7) Affidabilità: retrai, idempotenza, deadup

Chiave Idempotent: '(task _ type, business _ id, window)'; Ripetere la stessa ricevuta.
Retrai: back-off esponenziale + jitter, limite di tentativi, strategia on-errore (retry/cancel/compensate).
Poison-pill - Traduzione rapida in DLQ dopo N guasti, alert al proprietario.
Dedup: seen-cache (in-memory + KV) nella finestra TTL.
Effetti exactly-once: conferma degli effetti collaterali tramite registro/ricevute transazionali.


8) Gestione di attività lunghe e difficili

Chunking: ripartizione per batch, checkpoint/continuazione.
Time-boxing: vincolo CPU/IO/egress di rete Interrompere il progresso.
Sags/compensi: semantica «undo» per i passaggi interstatali.
Concurrency-caps - Limiti di attività simultanee per tipo/tenant/regione.


9) Osservabilità e metriche

Traces: 'trace _ id', passi della saga, chiamate esterne.

Metrics (SLI):
  • Lag prima della partenza, coda (lunghezza, età p95).
  • Success Rate, error-rate, retry-rate.
  • Latency p50/p95, time-to-complete.
  • Cost per 1k attività, egress/ingress.
  • DLQ rate, poison-pill rate.
SLO (esempio):
  • P0 partenza 60 c, P1 5 min; Success ≥ 99. 5%; DLQ ≤ 0. 1%; Freshness ≤ 30 da p95.

10) Verifica e prova

Ricevute: 'receipt _ hash' per avvio/successo/errore, firme DSSE per tipi critici (pagamenti, fogli di pregio, RTP).
WORM - Memorizza i fogli di esecuzione e i manifesti delle attività.
Chain-of-custody: chi ha messo/approvato/modificato il programma; Controlli soD.


11) Sicurezza e disponibilità

RBAC/ABAC/ReBAC: chi crea/approva/esegue; «Creare un pagamento» per «approvare».
JIT: il Worker richiede i token con TTL breve per l'operazione.
Isolamento: pool di worker per-tenant/region/griglia; esecuzione sandbox.
Igiene PII - Maschera/Torninizzazione, disabilitazione della logica primaria.


12) FinOps e costo

Budget/cap-alert per compute/storage/egress.
Scale auto dei worker in coda e SLO.
Classi di conservazione: archivio caldo (7-30 giorni) OLAP (6-24 mes).
Cost-aware pianificazione: finestra di lancio in «orologi low cost», limiti di egress.


13) Modello di dati (semplificato)

`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) Contratti API (gestione/integrazione)

POST/schedule - Crea una pianificazione (cron/cal, tz, finestre).
«POST/jobs» - mettere ad hoc; Restituisci «job _ id», «receipt _ hash».
«GET/jobs/{ id}» è stato/login/ricevuta.
«POST/jobs/{ id }/cancel» è una cancellazione con rimborso.
«GET/queues/stats» - lunghezza, lame, p95.
Вебхуки: `JobStarted`, `JobSucceeded`, `JobFailed`, `JobDroppedToDLQ`, `SLOViolated`.


15) Playbook (script tipici)

Retry-storm - Attiva il back-off globale, eleva i timeout delle dipendenze, attiva il circuito-breaker, spezza le battaglie.
Valanga DLQ - Interrompere la ricezione, dare priorità all'analisi del DLQ e tamponare le nuove attività.
Il leader è caduto: rielezione, verifica delle «doppie pubblicazioni» sull'idempotenza, verifica.
Fornitore di servizi (PSP/KYC) - Percorso a riserva, riduzione della frequenza di polling/webhoop, messa in quarantena delle transazioni.
La fuga dei segreti del Worker è il ritiro delle chiavi, la rotazione, la ricerca di lanci «anomali» in 30 giorni, la revoca dei diritti.


16) Specificità iGaming/Fintech

Pagamenti/pagamenti: pacchetti asincroni con ricevute, quarantena di transazioni grigie, repliche di code con deduplicazione.
RTP finestre/limiti - Chiusura in calendario, osservata da vs RTP teorico, auto-pausa promo alla deriva.
Fogli di lavoro/FX/Tax - Pubblicazioni pianificate, versioni degli artefatti, forza-invalidità cache.
Gli affiliati sono: compressione delle conversioni, deducibilità dei webhoop, atti/firme, esorcismo delle controversie.


17) Metriche di qualità (esempio di set)

Schedule Adherence: la percentuale di attività iniziate nella finestra è del 99%.
Queue Lag p95: P0 da 60 c, P1 da 5 min.
Success/Retry/DLQ Rate: ≥ 99. 5% / ≤ 0. 4% / ≤ 0. 1%.
Idempotency Errors: ≤ 0. 01%.
Cost/1k jobs e Egress/job - entro il budget.
Audit Completeness: 100% di operazioni critiche con ricevute.


18) RACI

AreaRACI
Architettura pianificatorePlatform/SRECTOData, SecurityProduct
Criteri/SoD/calendarioCompliance/IAMCCO/CISOLegal, OpsTutti
Osservabilità/SLOSREHead of EngData, FinOpsSupport
Economia/quoteFinOpsCFO/CTOSRE, ProductBU Leads
Playbook criticiIR TeamCOOPartners, LegalAudit

19) Assegno foglio di implementazione

  • Selezionare classi di attività, priorità e SLA; definire calendari e timesoni.
  • Inverti Scheduler/Dispatcher/Queue/Workers con il leader elettrico e il charding.
  • Immettere idempotenza, retrai, DLQ, compensi (sagra).
  • Configura i segreti RBAC/ABAC/ReBAC, SoD e JIT per i worker.
  • Abilita traces/metrics/logs, dashboard e alert; SLO и error-budget.
  • Ricevute firmate (DSE) e registri WORM per tipi critici.
  • Scale automatico e cap-alert a costi contenuti (compute/storage/egress).
  • Playbook: retry-storm, valanga DLQ, guasto del leader, degrado del provider.
  • Test: GameDay per ogni playbook, iniezioni di ritardi/errori.
  • Pianificazione regolare degli orari, delle code e dell'automazione REI.

20) FAQ

Perché il cron non basta?
Senza code, idampotenza, blocchi e verifiche, il cron si rompe su guasti e fusi orari.

È possibile combinare time-based con event-driven?
Sì: cron - assicurazione catch-up; gli eventi sono per la reattività.

Come si ottiene esattamente un giorno?
Deadup chiave, registro degli effetti transazionali, ricevute e attività collaterali idipotenti.

Cosa fare con i Jobs Duraturi?
Chank, checkpoint, time-boxing, possibilità di interrompere e continuare.

Come non mangiare il budget?
Scale automatico per code e SLO, orologi low cost per il pesante, cappe rigide egress/compute.


Riepilogo: Pianificatore e attività di sfondo sono la catena di montaggio di produzione della piattaforma. Integrando gli orari e le code, idipotenza, blocchi e osservabilità, aggiungendo ricevute/verifiche, l'isolamento dei tenenti e il controllo FinOps, si otterranno tempi prevedibili di esecuzione, recovery veloce e operazioni legali in qualsiasi regione e carico di lavoro.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.