Should a process be responsible for scheduling itself?

Question

I need to create a very small service which will programmatically make a database insertion once a day. As our stack primarily uses Node.js, we’re going to write a JS script responsible just for making the insertion and then ending execution. We will then cron that script for daily execution. However, the script itself, while still theoretically useful on its own, doesn’t really fulfill a major need without the scheduling component.

In addition, we try to setup all our services to be able to automatically deploy themselves in the event of an environment move/rebuild or something, so there’s a need to make sure the scheduling aspect of our application is captured in that automation. The question is how?

In my opinion, the service should also be responsible for scheduling itself. My personal opinion is to handle this in the package.json file, which would have a build option that runs something that adds itself the to the cron. This way, I think we’re still able to achieve a separation of concerns: the script itself which is able to do its insertion, and the build file/command, which is responsible for scheduling the script.

However, I’m not sure this is the best way, just the best way I can immediately think of without going overboard on what is an otherwise very simple script. Thoughts?

Answer 1

Pretty much anything that aligns with build/deploy cycle should be made part of it. In lieu of any other considerations, I see no reason to require a separate management of such things. I find your approach to be reasonable if we consider the scheduling to be part of the build.

I'm a little unsure of why you would have something like this in a design in the first place and I associate the use of cron jobs with production issues and vulnerabilities. But given this design, I don't see a problem with your plan other than what Ewan mentions in his answer about potential scaling issues.

Answer 2

Create a script which creates all your cron jobs, idempotently. You deploy it just the same way you deploy your services. Now all of your schedule is in one place, you want to change your schedule for anything you change it there and deploy it, you don't have to change the code or config of any service - which you might not want to do to just change the schedule ...

The schedule for your (periodic) services is a separate concern from the services themselves, and should be created/managed separately.

(Just as the health check that ensures your services are always running is a separate concern from your services and you create/manage that separately - even though each service provides it's own heartbeat/health check url it does not - cannot! - ensure it stays healthy itself).

Answer 3

I always feel that whenever you have to do something every X time there is a design fail.

Either you aren't capturing triggering events, or you have missed a way of calculating the event after the fact.

However, if you have to, then my I would advise having a service that runs 24/7 and does its own scheduling rather than using a scheduler to run a one off task every X time units.

This removes the problem of "setup the schedule" and gives you more control over things like:

• I've installed to two boxes, how do i make sure i don't get twice as many events?

• The scheduler crashed and I didn't notice until after the event should have happened

• The task took longer than the scheduled interval, should I start it again or wait for it to finish?

• Various failure other scenarios

• I need to run more often than once a min