Zum Inhalt springen
TypFreigeschaltetPhaseFleetSchwierigkeitFortgeschrittenAufgabeMulti-Tenant SaaSFürDev TeamsFürBackend-DevsServicesCronServicesContainersWarum HoodyContainer-ÖkonomieWarum HoodyHTTP-nativBrancheSaaS
TypFreigeschaltetPhaseFleetSchwierigkeitFortgeschrittenAufgabeMulti-Tenant SaaSFürDev TeamsFürBackend-DevsServicesCronServicesContainersWarum HoodyContainer-ÖkonomieWarum HoodyHTTP-nativBrancheSaaS
TypFreigeschaltetPhaseFleetSchwierigkeitFortgeschrittenAufgabeMulti-Tenant SaaSFürDev TeamsFürBackend-DevsServicesCronServicesContainersWarum HoodyContainer-ÖkonomieWarum HoodyHTTP-nativBrancheSaaS
TypFreigeschaltetPhaseFleetSchwierigkeitFortgeschrittenAufgabeMulti-Tenant SaaSFürDev TeamsFürBackend-DevsServicesCronServicesContainersWarum HoodyContainer-ÖkonomieWarum HoodyHTTP-nativBrancheSaaS
Zurück zu Use Cases
use-cases / byo-cron-per-tenant / hero
BYO Cron / Zeitpläne pro Tenant

Lass deine Kunden ihren eigenen Cron-Zeitplan mitbringen.

Deine Kunden tippen den Cron-Ausdruck. Du POSTest ihn an die crontab ihres Containers. Es gibt keine geteilte Queue zum Fair-Sharen, kein Mindestintervall durchzusetzen, kein Support-Ticket über „warum mein Job am Spitzen-Montag nicht lief".

Cron-API-Docs lesen
use-cases / byo-cron-per-tenant / mechanism

Der Kunde tippt in dein UI. Du POSTest an seinen Container.

Deine Settings-Seite rendert ein Eingabefeld. Sein Tenant-Container exponiert eine Cron-API. Submit leitet einen POST weiter. Kein globaler Scheduler, keine Per-Tenant-Filter-Logik, kein „max 100 Jobs über alle Kunden"-Cap.

your-backend → tenant-container
POST /users/root/entries
// der Form-Submit leitet den Ausdruck des Kunden unverändert weiter
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
}

// der Zeitplan ist jetzt in der crontab dieses Tenants und nirgendwo sonst

Der Hoody-Cron-Service läuft in jedem Tenant-Container mit verwalteten Einträgen und Per-User-Isolation. Der Zeitplan lebt, wo die Arbeit läuft.

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

Was BYO Cron dir gibt, das ein geteilter Scheduler nicht kann.

Wenn der Zeitplan neben der Arbeit lebt, ändern sich die Regeln des Multi-Tenant-Schedulings. Die Constraints sind lokal. Der Blast Radius ist lokal. Die Features sind lokal.

keine geteilte Queue

Keine Fair-Queueing-Steuer

Es gibt keinen globalen Thread-Pool, um den man kämpft. Dein anspruchsvollster Tenant läuft jede Minute und lässt deine ruhigen nie verhungern — sie sind nicht auf derselben crontab.

Self-Service

Kunden bedienen sich selbst, du validierst nicht

Du hörst auf, der Gatekeeper zu sein, der entscheidet „ist */1 * * * * für deinen Tier erlaubt?" Sein Container, sein Cron, seine CPU-Rechnung. Dein Support-Posteingang leert sich.

Container-gebunden

Der Zeitplan reist mit dem Tenant

Snapshotte den Tenant-Container, du snapshottest die crontab. Rollback, Restore, Fork — die Zeitpläne kommen mit. Kein externer Scheduler-State zu syncen.

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

Geteilter Multi-Tenant-Scheduler vs. Container-gebundener Cron.

Der Unterschied zeigt sich an drei Stellen: in der Erfahrung des Kunden, deiner Support-Last und der Engineering-Oberfläche.

Achsegeteilter SchedulerBYO Container-Cron
Was der Kunde wählen kann
5-Minuten-Minimum, nur Werktage, keine parallelen LäufeTier-gegated, Fair-Share-Regeln, Spitzenstunden-Defer
Jeder 5-Feld-Cron-Ausdruck, den sein Container handhaben kann*/1 * * * * wenn er will; seine CPU zahlt dafür
Wo Validierung passiert
Dein Code, vor dem Persistieren, gegen ein globales Queue-ModellRegex + Capacity-Check + Tier-Check + Overlap-Check
Der Cron-Daemon des Containers parst den Ausdrucknur Syntax; Capacity ist die eines Containers, nicht der Flotte
Failure-Blast-Radius
Der langsame Job eines Tenants stallt die Queue für alleNoisy-Neighbor-Vorfälle, Alerting auf Queue-Tiefe
Der Cron eines Containers laggt einen TenantKernel-Level-Isolation; der Rest der Flotte merkt nichts

Die Geteilter-Scheduler-Version dieses Features ist ein Meer aus Vorbehalten. Die BYO-Version ist ein Eingabefeld mit fünf Feldern.

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

Was wegfällt, wenn der Cron pro Tenant ist.

Drei Zahlen, die sich an dem Tag ändern, an dem du aufhörst, eine globale Queue zu betreiben. Jede entspricht einem Feature, das du nicht mehr schreiben oder betreiben musst.

  1. zu wartende Validierungsregeln0

    Kein Tier-gegatetes Mindestintervall mehr, kein Max-Jobs-pro-Tenant, keine Fair-Share-Knöpfe. Der Container ist das Limit.

  2. POST pro Schedule-Erstellung1×

    Kunde tippt, du leitest weiter, der Container parst. Der Settings-Seiten-Submit ist ein einziger REST-Call, keine Orchestrierung.

  3. Felder, die der Kunde besitzt5

    Minute · Stunde · Tag-des-Monats · Monat · Wochentag. Plus Makros (@hourly, @daily). Standard-POSIX, keine deine DSL.

Zahlen spiegeln das BYO-Container-gebundene Modell wider — tatsächliche Cron-Einträge skalieren mit der CPU jedes Containers und dem Plan des Kunden.

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

Der Cron-Ausdruck des Kunden ist seiner, nicht deiner zum Validieren gegen eine globale Queue.

geteilter SchedulerBYO Per-Tenant-Cron
vorherif (tier !== 'enterprise' && interval < 5min) reject()Validierungssteuer: jeder Kunde zahlte für den schlechtesten Kunden
nachherPOST /users/root/entries → 201 Createdder Zeitplan lebt in seinem Container; seine CPU, seine Regeln
Cron-API ansehen
use-cases / byo-cron-per-tenant / replaces

Was das ersetzt.

Die Infrastruktur-Stücke, die ein BYO-Container-gebundener Cron leise in den Ruhestand schickt.

  • geteilte Multi-Tenancy-Schedulerkeine globale Queue zum Fair-Sharen
  • Quartz mit Tenant-Filterungkeine tenant_id-Spalte auf jeder Job-Zeile
  • Custom-Cron-as-Config-UIsKunden tippen, der Container parst
  • Vendor-managed Airflowkein DAG-Service für einen 5-Feld-Ausdruck
  • geteiltes Sidekiq mit Throttlingkein globaler Rate-Limiter über Tenants hinweg
  • BullMQ mit Tenant-Queueskein Redis pro Kunde zu hüten
use-cases / byo-cron-per-tenant / cta

Hör auf, der Gatekeeper für jemand anderes Zeitplan zu sein. Übergib ihm das Cron-Feld, übergib die Arbeit seinem Container.

Docs lesen
use-cases / byo-cron-per-tenant / related

Lies die anderen