GH GambleHub

Planificador y tareas de fondo

(Sección: Operaciones y Gestión)

1) Asignación

El planificador y las tareas de fondo garantizan el funcionamiento fuera de uso de la plataforma: cálculos periódicos, publicaciones de artefactos, compensación y réplicas de colas. Los objetivos son determinismo, resistencia a fallas y capacidad de audiencia.


2) Taxonomía de tareas

Tiempo-basado: programado (cron/calendario): compensación, cierre de ventanas RTP, descarga, archivado.
Event-driven: disparadores de bus (PaymentsSettled, PriceListUpdated).
One-off/Ad-hoc: frijoles únicos con TTL.
Long-running: backoff/sagas, compactos de streaming.
Mantenimiento: rotación de claves, repequis, índices, calentamiento de caché.


3) Arquitectura (referencia)

Componentes:

1. Scheduler (control-plane): almacena horarios, CAL/cron, ventanas de servicio, temporizadores, limitadores.

2. Dispatcher: el plan → cola (per-priority/tenant/region), coloca los deduplines, las llaves idempotentes.

3. Workers: Static/Autocaravana para grupos de tareas; heartbeats, leases.

4. Queue/Bus: FIFO/priorización, DLQ, mensajes diferidos.

5. Locker/Coordination: bloqueos distribuidos (leases), líder de elección (Raft/ZK/Consul).

6. Vault/KMS: Secretos JIT, TTL cortos.

7. Observabilidad: traces/metrics/logs, dashboards, alertas.

8. Audit/WORM: recibos de ejecución inmutables, cortes de Merkle.

Patrones: outbox/CDC, idempotency, compensation (sags), backpressure, circuit-breakers.


4) Horarios: cron y calendarios

Cron v3: segundo/minuto/hora/día/mes/día-semana; soporte «/5 », rangos, listas.
Calendarios/excepciones: calendario de negocios, «ventanas de silencio», vacaciones/DST.
Temporizadores: almacena 'tz' en la tarea; Ejecutar en tiempo local tenant.
Multirregión: copias de horarios por región o «región líder + seguidores» con derivación/trasbordo.


5) Colas, prioridades, SLA

Clases de prioridad: P0 (crítico), P1, P2, P3; grupos individuales de workers.
SLA/deduplines: 'must _ start _ by', 'must _ finish _ by'; Paso - Escalamiento/Retiro.
Cuotas y fairness: caps en tareas/min/tenant, tokens en «burst», aislamiento noisy-neighbors.
Tareas pendientes: «no antes» (delay/visibility timeout).


6) Competitividad y bloqueo

Leases: alquiler de trabajo con renovación de coche (heartbeat); en tiempo de espera - re-presentación.
Mutex/semáforos: per-recurso (por ejemplo, «lista de precios x escribe sólo un worker»).
Charding: por 'tenant/region/hash (key)'; sticky-routing para caché y localización de datos.
Líder-elección: un líder publica «sistema» joba (por ejemplo, «cerrar todas las ventanas RTP»), seguidores - caliente standby.


7) Fiabilidad: retraídas, idempotencia, dedoup

Clave idempotente: '(task_type, business_id, window)'; repeticiones → el mismo recibo.
Retraye: back-off exponencial + jitter, límite de intento, estrategia on-error (retry/cancel/compensate).
Poison-pill: transferencia rápida a DLQ después de N fallas, alerta al propietario.
Dedup: seen-cache (in-memory + KV) en la ventana TTL.
Efectos Exactly-once: confirmación de efectos secundarios a través del registro de transacciones/recibos.


8) Administrar tareas largas y pesadas

Chunking: desglose en batches, checkpoints/continuación.
Tiempo-boxeo: restricción de la CPU/IO/egresos de red; interrupción con mantenimiento del progreso.
Sagas/compensaciones: semántica «undo» para pasos interservicios.
Concurrency-caps: límites de tareas simultáneas por tipo/tenant/región.


9) Observabilidad y métricas

Traces: 'trace _ id', pasos de la saga, llamadas externas.

Metrics (SLI):
  • Registro antes del inicio, cola (longitud, edad p95).
  • Success Rate, error-rate, retry-rate.
  • Latency p50/p95, time-to-complete.
  • Costo por 1k tareas, egress/ingress.
  • DLQ rate, poison-pill rate.
SLO (ejemplo):
  • P0 inicio ≤ 60 s, P1 ≤ 5 min; Success ≥ 99. 5%; DLQ ≤ 0. 1%; Freshness (taladro) ≤ 30 con p95.

10) Auditoría y probabilidad

Recibos: 'receipt _ hash' al inicio/éxito/error, firmas DSSE para tipos críticos (pagos, listas de precios, RTP).
WORM: almacenar registros de ejecución y manifiestos de tareas.
Cadena de custodia: quién puso/aprobó/modificó el horario; Comprobaciones SoD.


11) Seguridad y accesos

RBAC/ABAC/ReBAC: quién crea/aprueba/ejecuta; SoD: «crear pago» ≠ «aprobar».
Secretos JIT: el worker solicita los tokens con un TTL corto por scop de la tarea.
Aislamiento: grupos de los workers per-tenant/region/malla; sandbox-performance.
Higiene PII: enmascaramiento/tokenización, prohibición de lógica primaria.


12) FinOps y costo

Presupuestos/cap-alert en compute/storage/egress.
Auto skale de los trabajadores en colas y SLO.
Clases de almacenamiento: caliente (7-30 días) → OLAP (6-24 meses) → archivo.
Planificación de costo-aware: ventana de lanzamiento en «relojes baratos», límites en egresos.


13) Modelo de datos (simplificado)

`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) Contratos API (gestión/integración)

'POST/schedules' - crear un horario (cron/cal, tz, ventanas).
'POST/jobs' - poner ad-hoc; devuelve 'job _ id', 'receipt _ hash'.
'GET/jobs/{ id}' - estado/registro/recibos.
'POST/jobs/{ id }/cancel' - cancelación con compensación.
'GET/queues/stats' - longitudes, lagunas, p95.
Вебхуки: `JobStarted`, `JobSucceeded`, `JobFailed`, `JobDroppedToDLQ`, `SLOViolated`.


15) Playbucks (scripts tipo)

Retry-storm: habilita el back-off global, eleva los tiempos de espera de las dependencias, habilita circuit-breaker, aplastando batches.
Avalancha DLQ: detener la recepción, priorizar el análisis de DLQ, búfer nuevas tareas.
El líder cayó: superación, verificación de «publicaciones dobles» por idempotencia, auditoría.
Raya del proveedor (PSP/KYC): ruta a la reserva, reducir la frecuencia de polling/webhooks, poner las transacciones en cuarentena.
Filtración de secretos del worker: revocación de claves, rotación, búsqueda de lanzamientos «anómalos» en 30 días, rugido de derechos.


16) Especificidad de iGaming/fintech

Pagos/pagos: jobs asíncronos con recibos, cuarentena de transacciones «grises», repetición de colas con dedoop.
Ventanas/límites RTP: cierre por calendario, RTP teórico observado vs, auto-pausa promo durante la deriva.
Listas de precios/FX/Tax: publicaciones programadas, versiones de artefactos, memoria caché con discapacidad de fuerza.
Afiliados: conciliación de conversiones, dedoop webhooks, actas/firmas, depósito de disputas.


17) Métricas de calidad (conjunto de ejemplo)

Schedule Adherence: porcentaje de tareas iniciadas en la ventana ≥ 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 y Egress/job - dentro del presupuesto.
Audit Completeness: 100% de tareas críticas con recibos.


18) RACI

ÁmbitoRACI
Arquitectura del planificadorPlatform/SRECTOData, SecurityProduct
Políticas/SoD/calendarioCompliance/IAMCCO/CISOLegal, OpsTodo
Observabilidad/SLOSREHead of EngData, FinOpsSupport
Economía/CuotasFinOpsCFO/CTOSRE, ProductBU Leads
Reproductores críticosIR TeamCOOPartners, LegalAudit

19) Lista de verificación de implementación

  • Resaltar clases de tareas, prioridades y SLA; definir calendarios y zonas de tiempo.
  • Desplegar Scheduler/Dispatcher/Queue/Workers con selección líder y charding.
  • Introducir idempotencia, retraídas, DLQ, compensación (sagas).
  • Configurar los secretos RBAC/ABAC/ReBAC, SoD y JIT para los trabajadores.
  • Incluir traces/metrics/logs, dashboards y alertas; SLO и error-budget.
  • Recibos firmados (DSSE) y registros WORM para tipos críticos.
  • Auto-scale y cap-alert al costo (compute/storage/egress).
  • Playbooks: tormenta retry, avalancha DLQ, fracaso del líder, degradación del proveedor.
  • Pruebas: GameDay para cada playbook, inyecciones de retraso/error.
  • Rutina de rugido de horarios, ráfagas y ROI de automatización.

20) FAQ

¿Por qué cron no es suficiente?
Sin colas, idempotencia, bloqueos y auditorías, cron se rompe en fallas y zonas horarias.

¿Es posible combinar tiempo-basado y evento-conductor?
Sí: cron - seguro para catch-up; eventos - para reactividad.

¿Cómo puedo lograr «exactamente un día»?
Dedoup por clave, registro transaccional de efectos, recibos y acciones colaterales idempotentes.

¿Qué hacer con los jobs «largos»?
Chunk, checkpoints, time-boxing, posibilidad de abortar y continuar.

¿Cómo no «comer» el presupuesto?
Auto scale en colas y SLO, relojes baratos para pesados job, tapas rígidas egress/compute.


Resumen: El planificador y las tareas de fondo son el transportador de producción de la plataforma. Incorporando horarios y colas, idempotencia, bloqueos y observabilidad, agregando recibos/auditorías, aislamiento de tenantes y control FinOps, obtendrá plazos de ejecución predecibles, recuperación rápida y operaciones legalmente sostenidas en cualquier región y carga.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.