Aller au contenu
TypeDéverrouilléÉtapeParcDifficultéAvancéTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natifSecteurSaaS
TypeDéverrouilléÉtapeParcDifficultéAvancéTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natifSecteurSaaS
TypeDéverrouilléÉtapeParcDifficultéAvancéTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natifSecteurSaaS
TypeDéverrouilléÉtapeParcDifficultéAvancéTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natifSecteurSaaS
Retour aux cas d'utilisation
use-cases / byo-cron-per-tenant / hero
BYO cron / plannings par tenant

Laissez vos clients apporter leur propre planning cron.

Vos clients tapent l'expression cron. Vous l'envoyez en POST au crontab de leur conteneur. Pas de file partagée à équilibrer, pas d'intervalle minimum à imposer, pas de ticket de support sur "pourquoi mon job n'a pas tourné le lundi de pointe".

Lire la doc de l'API Cron
use-cases / byo-cron-per-tenant / mechanism

Le client tape dans votre interface. Vous envoyez en POST à leur conteneur.

Votre page de paramètres affiche un champ de saisie. Leur conteneur tenant expose une API Cron. La soumission relaie un POST. Pas de planificateur global, pas de logique de filtrage par tenant, pas de plafond "max 100 jobs sur tous les clients".

your-backend → tenant-container
POST /users/root/entries
// la soumission du formulaire relaie l'expression du client telle quelle
POST https://acme-cron.hoody.com/users/root/entries
Content-Type: application/json

{
  "schedule": "0 9 * * 1-5",
  "command": "/jobs/sync_crm.sh",
  "comment": "Sync Salesforce contacts",
  "enabled": true
}
tenant-container → your-backend
201 Created
HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "sch_8a3f1c",
  "schedule": "0 9 * * 1-5",
  "next_run": "2026-05-04T09:00:00Z",
  "enabled": true
}

// le planning est maintenant dans le crontab de ce tenant et nulle part ailleurs

Le service Hoody Cron tourne dans chaque conteneur tenant avec des entrées gérées et l'isolation par utilisateur. Le planning vit là où le travail s'exécute.

use-cases / byo-cron-per-tenant / powers

Ce que le BYO cron vous donne qu'un planificateur partagé ne peut pas.

Quand le planning vit à côté du travail, les règles du planning multi-tenant changent. Les contraintes sont locales. Le rayon d'impact est local. Les fonctionnalités sont locales.

pas de file partagée

Pas de taxe de file équitable

Il n'y a pas de pool de threads global pour lequel se battre. Votre tenant le plus exigeant tourne toutes les minutes et n'affame jamais les calmes — ils ne sont pas sur le même crontab.

self-service

Les clients se servent, vous ne validez pas

Vous arrêtez d'être le gardien de "est-ce que */1 * * * * est autorisé pour votre palier ?". Leur conteneur, leur cron, leur facture CPU. Votre boîte de support se vide.

lié au conteneur

Le planning embarque avec le tenant

Snapshot du conteneur tenant, snapshot du crontab. Rollback, restore, fork — les plannings suivent. Pas d'état de planificateur externe à synchroniser.

use-cases / byo-cron-per-tenant / compare

Planificateur multi-tenant partagé vs cron lié au conteneur.

La différence apparaît à trois endroits : l'expérience du client, votre charge de support et la surface d'ingénierie.

axeplanificateur partagécron conteneur BYO
Ce que le client peut choisir
minimum 5 minutes, jours ouvrés uniquement, pas d'exécutions concurrenteslimité par palier, règles d'équité, reports en heures de pointe
Toute expression cron à 5 champs que leur conteneur peut gérer*/1 * * * * s'ils le veulent ; leur CPU paie pour ça
Où la validation a lieu
Votre code, avant persistance, contre un modèle de file globalregex + check de capacité + check de palier + check de chevauchement
Le démon cron du conteneur parse l'expressionsyntaxe seulement ; la capacité est celle d'un conteneur, pas de la flotte
Rayon d'impact en cas de panne
Le job lent d'un tenant bloque la file pour tout le mondeincidents de voisin bruyant, alertes sur la profondeur de file
Le cron d'un conteneur ralentit un tenantisolation au niveau noyau ; le reste de la flotte ne s'en aperçoit pas

La version planificateur partagé de cette fonctionnalité est une mer de réserves. La version BYO est un champ de saisie à cinq champs.

use-cases / byo-cron-per-tenant / support

Ce qui disparaît quand le cron est par tenant.

Trois chiffres qui changent le jour où vous arrêtez d'exploiter une file globale. Chacun correspond à une fonctionnalité que vous n'avez plus à écrire ou à exploiter.

  1. règles de validation à maintenir0

    Plus d'intervalle minimum lié au palier, plus de max-jobs-par-tenant, plus de boutons de partage équitable. Le conteneur est la limite.

  2. POST par création de planning1×

    Le client tape, vous transférez, le conteneur parse. La soumission de la page de paramètres est un seul appel REST, pas une orchestration.

  3. champs que le client possède5

    minute · heure · jour-du-mois · mois · jour-de-la-semaine. Plus les macros (@hourly, @daily). POSIX standard, pas votre DSL.

Les chiffres reflètent le modèle BYO lié au conteneur — les entrées cron réelles s'adaptent au CPU de chaque conteneur et au plan du client.

use-cases / byo-cron-per-tenant / punchline

L'expression cron du client est celle du client, pas la vôtre à valider contre une file globale.

planificateur partagécron BYO par tenant
avantif (tier !== 'enterprise' && interval < 5min) reject()taxe de validation : chaque client payait pour le pire client
aprèsPOST /users/root/entries → 201 Createdle planning vit dans leur conteneur ; leur CPU, leurs règles
Voir l'API Cron
use-cases / byo-cron-per-tenant / replaces

Ce que cela remplace.

Les pièces d'infrastructure qu'un cron BYO lié au conteneur retire discrètement.

  • planificateurs multi-tenant partagéspas de file globale à équilibrer
  • Quartz avec filtrage par tenantpas de colonne tenant_id sur chaque ligne de job
  • interfaces cron-as-config customles clients tapent, le conteneur parse
  • Airflow géré par un fournisseurpas de service DAG pour une expression à 5 champs
  • Sidekiq partagé avec throttlingpas de limiteur de débit global entre tenants
  • BullMQ avec files par tenantpas de Redis à surveiller par client
use-cases / byo-cron-per-tenant / cta

Arrêtez d'être le gardien du planning de quelqu'un d'autre. Donnez-leur le champ cron, donnez le travail à leur conteneur.

Lire la doc
use-cases / byo-cron-per-tenant / related

Découvrez les autres