Part of our system that we’re migrating to Temporal currently uses Quartz Scheduler for scheduling user-land workloads via CRON. I’d like to replace this component with Temporal, but would like validation on the approach.
Our system allows users to create arbitrary DAG pipelines for software delivery, which can be triggered by various means, including one or more CRON expressions. We have not yet converted the DAG pipeline system to Temporal. In terms of scale, we have ~15,000 of CRON triggers and see a constant ~5-10 CRON trigger fires per second today. Whatever solution we come up with should be able to handle at least double the triggers, and (arbitrarily) 10x the trigger fires.
The way I’m thinking of approaching this is to create a CronScheduler workflow which uses Temporal’s built-in CRON support, creating an execution for each CRON trigger in the system that exists for the duration of the CRON trigger’s existence. This would then have a single activity inside that runs the DAG pipeline.
class CronSchedulerImpl : CronScheduler {
private val pipelineActivities = PipelineActivities.get()
override fun trigger(trigger: CronTrigger) {
pipelineActivities.trigger(trigger)
}
}
We’d then have 1000’s of these workflows running all of the time, and would cancel them when a trigger configuration was removed from a pipeline config, etc. Once we migrate the pipeline system to Temporal as well, these would continue to live outside of the pipeline workflows, given that Temporal does not support more than 1 cron expression per workflow execution.
I briefly thought about creating a scheduler workflow that had its own internal timer, but that seems like a lot of work (storing the cron triggers in some database, loading the schedules via an activity, finding ones that need to be fired / re-fired, then firing the trigger)… I’d basically be re-implementing Quartz - which I see no benefits from.
Does my current line of thought make sense? Are there other things I should consider?